We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Going Rogue: How Code.org Created a Curriculum Development Platform Without their Engineers All

00:00

Formal Metadata

Title
Going Rogue: How Code.org Created a Curriculum Development Platform Without their Engineers All
Title of Series
Part Number
44
Number of Parts
48
Author
Contributors
License
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
As a Middle School computer science teacher, I know enough to be dangerous, but not enough to consider myself a “real” developer. As a member of the curriculum team at Code.org (a nonprofit dedicated to providing all students with access to CS education), I knew that our combination of rendered markdown files and Google docs was far from the most effective way to write and deliver curriculum. If only we could schematize our curriculum writing, I thought, we’d be able to write more consistent lessons with better support for teachers to see which lessons are aligned to which standards, or where a given concept was first taught. When I brought this proposal to our engineering team everyone was excited about the idea, but there was no way we had the bandwidth to actually create it. Our small team of engineers are booked solid building tools for students to learn programming and for teachers to manage their classes. When it comes to the needs of our curriculum writers, we obviously need to come after the students and teachers. But wait, I know how to program. I did the “Two Scoops” tutorial. Why couldn’t I make the tool I had dreamed of? Using Django and Mezzanine as a base, I gradually built a system that allows Code.org curriculum writers to write faster, more consistent, and better supported lessons at a massive scale. Along the way, I also dealt with the very real concerns of my engineering team. How can we be sure this will scale to our 10’s of thousands of teachers? What about our millions of students? How can we be certain that this doesn’t introduce new security vulnerabilities to our site? Are you sure you know what you’re doing here? The answer to all of these problems was surprising simple, and has allowed me to address the needs of our curriculum team without taking the engineering team’s focus away from the customers that really matter - teachers and students. After many months of development, CurriculumBuilder has become an essential internal tool for curriculum writing at Code.org, and continues to find new ways to solve problems that would otherwise go unaddressed. Not bad for a Middle School CS teacher who had never before written software used by others.
6
Thumbnail
42:19
Computing platformSoftware developerComputer animation
Software developerCodeComputer scienceRoboticsDegree (graph theory)Online helpSoftware developerVideo gameReal numberMereologyComputer animation
Student's t-testComputer scienceGroup actionWave packetCodeDifferent (Kate Ryan album)Branch (computer science)Student's t-testMeeting/Interview
Software engineeringFundamental theorem of algebraAlgebraElectronic mailing listFile formatDigital signalInformationStandard deviationCodeExtension (kinesiology)Process (computing)Content management systemWebsitePhase transitionConsistencyEndliche ModelltheorieDigital filterFluid staticsPoint (geometry)Link (knot theory)Control flowView (database)Meta elementSource codeLevel (video gaming)Arithmetic progressionStudent's t-testCodeComputing platformSoftware developerNeuroinformatikSet (mathematics)Student's t-testFood energyDifferent (Kate Ryan album)Computer programmingCellular automatonMultimediaE-learningForm (programming)Descriptive statisticsObject (grammar)Solid geometryDisk read-and-write headRight angleView (database)PlanningProbability density functionPhysical systemFile formatMultiplication signSlide ruleGoodness of fitGoogolComputer scienceAlgebraConsistencyMetadataReal numberFilter <Stochastik>Process (computing)Point (geometry)Interactive televisionFluid staticsBitLink (knot theory)Computer fileVideoconferencingDigitizingWritingInformationPattern languageMereologyLevel (video gaming)Office suiteArithmetic progressionInformation securityPhysical lawGame controllerSource codeWebsiteMultiplicationPrincipal idealData storage deviceAreaStandard deviationSweep line algorithmAmenable groupContent (media)WhiteboardTelecommunicationProduct (business)Projective planeAdditionElectronic program guideEntire functionExtension (kinesiology)Phase transitionWave packetSimilarity (geometry)Combinational logicWeb pageNP-hardComputer animation
Software frameworkReading (process)Streaming mediaWhiteboardBuildingFluid staticsOffice suiteStaff (military)TelecommunicationWebsiteServer (computing)Interactive televisionComputer animation
Data recoveryProbability density functionPhase transitionHost Identity ProtocolSummierbarkeitSign (mathematics)Execution unitMaxima and minimaSoftware frameworkIterationCodeMultiplication signLattice (order)Arithmetic meanView (database)Game controllerStudent's t-testComputer scienceHookingReflection (mathematics)Saddle pointPhase transitionOpen setProjective planePosition operatorSlide ruleProcess (computing)QuicksortPerspective (visual)Inclined planeControl flowRoundness (object)Machine codeRevision controlRollback (data management)Office suiteInternetworkingReverse engineeringLevel (video gaming)Physical systemNear-ringMechanism designArithmetic progression1 (number)Electronic program guidePlanningState of matterMoving averageDifferent (Kate Ryan album)GenderCodeConstructor (object-oriented programming)Interactive televisionReading (process)Form (programming)SatelliteFitness functionOnline helpSpacetimeVarianceIterationReal numberSign (mathematics)BuildingWebsiteComputer animation
JSONXML
Transcript: English(auto-generated)
Just so we know, this is my first talk at a technology conference.
I talk in front of thousands and thousands of teachers a year, but I don't ever talk in front of developers. So this is weird for me, and if I make like middle school-y jokes that don't land on you, just give me the benefit of the doubt. So, who am I? I am a recovering middle school teacher. I taught computer science and robotics and English in middle school for years and years before coming to code.org,
where I now develop computer science curriculum and help develop new teachers to teach computer science. I am not an engineer. I didn't come from an engineering background. I actually had my degree in theater before I taught. I've never like done a real-life engineering thing before this thing that I'm going to show you today.
But I am a glutton for punishment, which is how I ended up in this situation in the first place. Who is code.org though, if you don't know? Code.org, our mission is to ensure that every student in every school in America gets the opportunity to learn computer science. We do that in a lot of different ways.
So we have a branch that does advocacy and outreach and working with governments to help ensure that there's funding for computer science or that there's pathways for teachers to get trained. We have a whole group of folks that work with training teachers. We have groups that reach out to school districts to try and import the importance of computer science to them. And then they have my team, which actually makes the curriculum to teach computer science to those kids.
We are a relatively small team for the amount of work that we do. Of this small team, I guess you can't actually tell the difference between the yellow shirts, but about half those yellow shirts are our engineers. So we are a small team in general to do a lot of different things. And we have a relatively small engineering team. But we have a massive reach. We actually reach one in five students in American schools.
So one in five students in the entire United States of America uses some form of our curriculum. As I said, I just finished a summer of training up fifteen hundred new computer science teachers and we do that every year. So we do a lot of work with a really small team. To make that work happen, our engineers make some really pretty fantastic tools to teach programming and computer science.
So we have tools that let us teach programming in ways that are maybe interesting to students. You may have seen this programmable Minecraft that we worked with Microsoft on. We work on tools that make students, or allow students to be expressive. And that's really wonderful because we get to use those tools.
We get to design our courses around those tools. So this is, my bailiwick there is the middle school realm of things. So that's science, algebra, discoveries. Those are the courses I make. And we do a lot of different courses, but despite the great tools we have to use in our courses, we have historically had very poor tools to create those courses with.
You never put all of your energy on your in house stuff. You put your energy into the stuff that faces teachers and students. So as a curriculum developer, we had a real hard time making solid lessons for teachers because we were using a whole bunch of different platforms, whether it was Markdown, Google Docs, or PDF. We were manually creating all of these different overviews.
If you've never seen a curriculum, there's lessons, but then there's all of this other material that kind of combines them into different views that we had to make manually. There was no metadata. We were inconsistent about our style and our format. And there was a ton of tribal knowledge. We were a very small team, so every person who had kind of developed a system of working had that locked away in their head.
And it was very hard for somebody to join a new thing. Just to give you an idea of the kinds of things that go into a lesson plan, the things that we grapple with that we were doing in these Google Docs or Markdown files, every lesson plan has learning objectives. What do we want students to get out of it? We have materials, prep, things you might need, things you might need to do,
digital resources, videos, files, all kinds of stuff, new vocabulary that's introduced, new code that's introduced, an overview of purpose, tags, and keywords, related extension lessons, assessment information, aligned learning standards, just all of this stuff that gets fed into a lesson plan that was happening in these static pages. And if you updated one, you had to go and update a jillion other places.
It was painful. And so I said to myself, it can't be that hard. Why don't we just like make a thing that lets us write lesson plans the way we want to do it? Because I had asked our engineers, and they're very nice people, but they had a lot on their plate, and I was not their priority. So maybe unwisely, I decided I was going to try this out on my own.
So I had never done anything with Django before, but I liked Python. I taught Python. I thought, this doesn't seem too hard. I found a pretty cool package called mezzanine, which if you've seen it, is kind of a CMS-y package. It's got a lot of the things I wanted. I mashed them together and kind of cobbled together a thing that kind of did what I wanted,
and I brought it to my engineering team. And I was like, check out the beautiful thing I made. And I don't think that they saw that. I think they saw this. They gave me a pat on the head. They were like, good job, buddy. We're real proud of you. We'll put that on the fridge.
But we're not putting it on our website. They did, however, work with me a little bit. They said, all right, you really want this to happen. You want to have a new tool. You want to write better lesson plans. Here's our requirements. Whatever you make cannot interact with our main code.org site.
We don't want to introduce any security flaws. Whatever you do sits on its own thing. In fact, it's got to stay out of the ecosystem entirely. You can't be on our AWS account. You can't have any of our support, any of our tools, any of our anything. This lives in the woods. We're going to minimize any organizational dependency.
If this thing disappeared tomorrow because you made it so poorly, we should not know about it. So whatever you do should be able to continue existing without the tool. You're on your own for everything. If that was not clear before, we are not helping you with this. This is your own problem. By the way, it's got to support over 100,000 teachers.
That's, like, real easy, huh? And to support those 100,000 teachers, you get a budget of $0. And I think the intent was to, like, talk me off the edge. Clearly, nobody's going to pursue this.
This would be a terrible idea. I got a new plan. I'm a glutton for punishment, as I said earlier. So I said, all right, if I've got to do all of these things, right, if it's got to be able to live, if the tool dies, if it's got to be able to support 100,000 or a million or a jillion teachers, I know that static websites can do that. Maybe I'll just make a thing that generates a static website.
That'd be pretty easy. Sure. Why not? So phase two, we start calling this thing curriculum. It's got a name, so it's real. We host it on premise because, again, I've got a $0 budget, so I find an old computer, I throw it up in the office, and I start hosting it here for our internal use.
I make really, really opinionated models, and I develop my own markdown filters because one of our goals here is to eliminate all of that tribal knowledge that was locked away and build consistency. So by making opinionated approaches to writing lesson plans, we ensured that whoever jumped onto this tool was going to do it in a very narrow way.
I found a cool thing called Django Jack Frost, if you've not seen it. I looked through a bunch of different static site generators, and I found one that ended up working for me. I hooked it up to Django Storages to push it out to an S3 bucket, and then all I had to do to my engineers was say, point your links at this bunch of static files.
For all you know, I could have made these in Dreamweaver. It's a website. Have fun. So I was able to not live in their ecosystem. And it actually worked out really, really, really well, this first approach at a thing that I thought was going to fail. We had more consistent lessons. We had control over formatting. In fact, we could sweep over the whole course of things
and change them all at once, which was never something we could do before. Writers could self-publish. I built a little front-end thing so that they could click publish on their things, and now we don't have to ask engineers to push out new content points. It was really easy to update. It was really easy to create all those meta views. So if a principal came to me and said, I need a calendar of every standard that gets hit across this and mapped across the year,
I could make that because all the data existed now. This was really exciting for us. We still had a handful of challenges, though. We had multiple sources of truth before, but it was like a thousand multiple sources of truth, and now we had two, and that felt real weird. We have our online learning platform that my real engineers make,
and then we had this curriculum thing that I made. And there were places where they duplicated content. They didn't communicate. We had a lot more internal users joining this. We had interns starting to use it. We had teachers who we had onboarded starting to use it because it was such an easy way to write. Our curriculum started evolving. We got past the first year, and we wanted to change things,
and that introduced new issues. And probably the biggest challenge of all is this turned out to be like a really big project, and as I said before, no engineer am I, and this was the first real thing that I had ever made. So we enter phase three.
How do we consolidate truth and communicate between two tools that do very different things, but need to maintain a lot of similar content? So Level Builder, which is our tool that the engineers made for making all of our online learning progressions, knew things about level progressions that needed to know things about the instructions for students or teacher tips, the starting code for different projects,
exemplars, what a final project should look like. That's the truth that this tool should know. And my new tool, it should know the truth of the teaching guide and the additional resources and files and videos and lesson description and assessments and objectives and standards and all of those things on that slide that I was showing you before,
vocab, new code, whatever. And the goal was to have those things live in one place, but how am I ever gonna do that? I got my engineers to give me a JSON endpoint so I could get all of that good stuff out of Level Builder and put it into my lesson plans, but I was not allowed to communicate with our tools.
Remember, I gotta be outside of these streams. I cannot let my tool get into their tool. So I went back to the drawing board and I said, if static worked so well for everything else, could static work for JSON? And it turned out like, yeah, static could work for JSON.
It was kind of a cool discovery that I made that I could publish out essentially a static API and again, there is no communication. If my tool exploded tomorrow, if that server that's sitting in the corner of the office caught fire, no harm, no foul. I also was able to use this to build some more interactivity
into the lesson plans that we've made because if I had this API for the other site to access, I had it for our own site. So I started to take the static thing and make it a little less static with a little JavaScript and everybody was happy. All of those hundreds of thousands of teachers were using this. We've migrated all of our curriculum onto this thing and it actually kind of worked and it was amazing.
And that need for more users to be on the system and our curriculum evolved and I needed to be able to audit what was happening. There were teachers doing this, people who weren't in the office with me doing this. I needed to audit what they were doing, I needed to recover if anything had gone terribly awry. And I went back out to the internet and I said, there's got to be a package for this
and it turns out there were packages for this. It's amazing. So I found a package called Django Reversion which let me keep that version history and rollback and another one called Reversion Compare which gave me like a giddy kind of view into all of this work. So now I'm able to support all of those other people that are using this and I'm able to have some level of control
over whether what they make land. We also were able to expose some of this to teachers so now I can let my teachers know this was the last time a thing was updated and this is why. That big project thing though, that's still a problem.
I'm kind of in this phase of where the tool is right now. It definitely drives but no mechanic is gonna look at this. So there's progress yet to be made. But it works and I'm kind of amazed that it works.
Some takeaways that I found in doing this to give you perspective of somebody coming totally as an outsider having never done a thing like this, never worked with Django before. There's a package for damn near everything. These are some of the ones that I found the most useful but there were many, many more. Sometimes way too many.
And I think that is an issue for somebody coming to this new is that it is very difficult to canonically find the best thing to do a thing. And Django packages proved to be a very useful place for me to go but it still meant that sometimes I was testing out four or five or six different packages before I found something that kind of did what I wanted.
And I'd like to see somebody take ownership over really vetting and providing new users a guide to what's the best. Start small and don't be afraid to iterate. These are things that I tell my students that are really hard for me to take on.
And I think they're really hard for any of us. You want to start with the end point. You want to start with the thing that does all the beautiful things. But I was only able to get here because I took really small steps one at a time and each one built on the last one. There's a lot of tutorials out there but there's not as much great instruction.
And as an educator this is something that I want to bring to the community to say it's okay that there are tutorials that are just strictly tutorials. Meaning do this, do this, do this and you'll end up at an end point. But when you want to bring new users and new people into the fold you also need to help them identify where the great instruction is happening so you understand the concepts behind why you're doing this.
I think one of the biggest challenges that I found in going into Django was that when you go through the official tutorial there's like 47 different ways to set up a view. And it has you go through all of them and I don't know what the best way is for what I want to do. And so really thinking about how do we
instruct new users on how to wrap their minds around this is something I'd really like to see. You should take advantage of the community like I totally didn't. In fact this is the first time I have engaged with the Django community. I like to just jump into the deep end so why not talk at a conference as my first interaction with anybody.
But really I've been working on the Slack community for Seattle Django users forever but I've never engaged with them. I've never gone to a meeting. You should take advantage of this community because it is a very big and powerful community. Clearly if you're here you're doing that to some extent. Personally maybe this is more a reflection for me
but you might find use of this. Beware of I bet you can't or when all you have is a hammer mentality. This is something I found because I was now the sole engineer of a thing that I was the user for and my team were the users for. So it was really easy for them to kind of
saddle up next to me and go you know I bet you couldn't make this thing also support all of our documentation for all of our tools. Well now it does that too. I bet you couldn't hook it up to Slack so that we could publish from a Slack command or see what was going on. Well okay I guess we'll do that too.
I bet you couldn't hook it up to a tiny servo and a gong on our desk so that we could have a Slack command that rang a gong. Well I'm not real good at saying no. But it is kind of a cute little gong. So at least there's that.
I was really worried I was gonna go along on this so fortunately I did not. I wanna thank you but the real reason I came here is because I need help. I started this thing and it's now grown too big for me. And so I am here reaching out. We have engineering openings
but we also have a lot of volunteer engineers. The code.org slash about slash jobs. I don't know that there's a ton of postings right now but we're always taking engineering positions. The volunteer there is less for volunteering to help me figure this out. If you wanna do that please talk to me. That's for getting into classrooms. And we have teachers all over the country
who are begging to get people working in industry into the classrooms. They wanna get faces that look like their students faces so that they can have somebody tell them that this is a real thing that you can do. So I would really encourage you if you're at all interested in students to sign up on that because you will get posts from teachers saying could you just come in to talk to my kids about something.
Often they're not even computer science teachers. They're just teachers who know that computer science is important but they don't know what to do and you can help. That's the end of my slide. So I have time for questions. I don't know what you'd ask me now. Great talk, thank you.
My question is if you were to do it all over again knowing what you know now how would you do it differently? Oh, the smart answer was I wouldn't do it. Cause I still have my full time job writing curriculum and this takes just a lot of time. I honestly don't know that I would do it differently
than I had done it unless I came to it with prior knowledge. I would start with the static stuff. I would start really constrained and not build out all of these other features that turn out to be really nice things but do we really need them? I don't know. You said you were a middle school teacher originally?
Did you find as you were building this out that you drew references from your teaching experience and trying to think about it from the student's perspective sort of? Or were you able to use that experience? I found myself empathizing with my students a lot because it's really easy as the teacher to say
you need to plan and you need to take small steps and not bite off more than you can chew and then I would realize that I'd gone four days without committing and I was just like randomly going down a rabbit hole because that's the mentality that I got into. So it made me empathize with my students and every time I yell at them it's important that I yell at them
because we need to be reminded that the natural inclination is not to lay everything out ahead of us and plan and move very slowly but that doesn't make it easy even when you know that's what you ought to do. Then it's time for the break I believe. Which is downstairs. A round of applause.