Creating an Inclusive Django Community with Kenya Phelps
Published July 15, 2026
This video features Josh Caldwell at DjangoCon US 2017 in Spokane, Washington, USA.
DjangoCon US 2017 - Going Rogue: How Code.org Created a Curriculum Development Platform Without their Engineers All by Josh Caldwell
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.
This talk was presented at: https://2017.djangocon.us/talks/going-rogue-how-code-org-creating-a-curriculum-development-platform-without-their-engineers/
LINKS:
Follow Josh Caldwell 👇
On Twitter: https://twitter.com/mrjoshida
Official homepage: https://code.org
Follow DjangCon US 👇
https://twitter.com/djangocon
Follow DEFNA 👇
https://twitter.com/defnado
https://www.defna.org/
Josh Caldwell explains how, despite having no engineering background or prior Django experience, he built Curriculum, a tool for Code.org’s curriculum team to create structured lesson plans and generate static websites. Starting with Django, Mezzanine, custom Markdown filters, Django Jackfrost, and S3 storage, he kept the system isolated from Code.org’s main infrastructure while making it usable at large scale. The tool replaced scattered documents with a consistent source of structured content, later publishing static JSON to share data with Code.org’s online learning platform and adding version history with Django Reversion. Caldwell argues that beginners should start with a narrowly constrained problem, iterate in small steps, use the community and packages carefully, and seek better guidance about which Django patterns and packages to choose.
Summarised automatically from the transcript.
Automatically transcribed, so expect mistakes in names and technical terms.
Speaker 1: Thank you. Uh just just so we know, uh this is my first talk at a technology conference. I talk in front of uh 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 uh 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
Speaker 1: 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 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 teaching. 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.
Speaker 1: 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 a American schools. So one in five students in the entire United States of America uses some form of our curriculum. As he said, I I just finished a summer of training up 1,500 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 we have tools that let us teach programming in ways that is uh maybe interesting to students. You may have seen this uh programmable Minecraft that we worked with.
Speaker 1: uh Microsoft on. We work on tools that make students uh 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 my bailiwick there is the middle school realm of things. So that's science, algebra, CS discoveries , those are the courses I make. And we 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, right? We're the, you know, 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. teachers because we were using a whole bunch of different platforms whether it was Markdown or Google Docs or PDF.
Speaker 1: 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, right? 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 of 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, a purpose, tags and keywords, related extension lessons, assessment informations, aligned learning standards, it's all of this stuff that gets
Speaker 1: 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 , can't be that hard. Why 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 gonna try this out on my own. So I had never done anything with Django before, but I like Python. I've taught Python. But 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.
Speaker 1: 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 were they 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 uh we're not putting it on our website They did, however, work with me a little bit. They said, alright, 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.
Speaker 1: thing. In fact, it's gotta like 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 gotta support over a hundred thousand teachers. That's like real easy, huh? And to support those hundred thousand teachers, you get a budget of zero dollars
Speaker 1: And I think the intent was to like talk me off the edge. Clearly nobody is going to pursue this. This would be a terrible idea. I got a new plan. I'm 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 gotta be able to live if the tool dies, if it's gotta be able to support a hundred thousand 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 zero dollar budget. So I find an old computer, I throw it up in the office, and I say start hosting it here for our internal use.
Speaker 1: 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 consistent 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 Jackfrost, 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 DreamWorks. They just they're it's a website, have fun. So I I was able to not live in their ecosystem.
Speaker 1: And it actually like worked out really, really, really well. This this first approach at a thing that I thought was gonna 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. for us. 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. uh you know 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.
Speaker 1: 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 make 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 onboard 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'd ever made. So, we enter phase three. In progress.
Speaker 1: 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 and code, whatever. And the goal was to have those things live in one place. But how am I ever gonna do that?
Speaker 1: Well 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, right? Remember I I gotta be outside of these the stream. 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. That 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
Speaker 1: No harm, no foul. I also was able to use this to build some more interactivity into the 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 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 curricula evolved meant I needed to be able to audit what was happening. There were teachers doing that. 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 gotta be a
Speaker 1: 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 roll back. 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 to have some level of control over whether what they make lands. 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 Which was kind of cool. That big project thing, though, that's still a problem. Uh I'm kind of in this phase of of where the tool is right now.
Speaker 1: It definitely drives, but no mechanic is going to look at this So there's there's progress yet to be made. But it works, and I I'm kind of amazed that it works. Some takeaways that I found in doing this to To give you perspective of somebody coming totally as an outsider, having never never done a thing like this, never worked with Django before. There's a package for damn near everything. Um so these are some of the ones that I found the most useful, but there there were many, many more. Uh sometimes way too many. And and I think that is a an issue for somebody coming to this new is that it is very difficult to canonically find the best thing to do a thing.
Speaker 1: 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 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, right? You want to start with the endpoint. You want to start with a 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
Speaker 1: 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 endpoint. 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 how to wrap their minds around this is something I'd really like to see.
Speaker 1: 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, there's like I've been I've been lurking 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 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 uh or the all when all you have is a hammer mentality. This is something I found because I was now
Speaker 1: 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 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 like publish from a Slack command or See what was going on and who out 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.
Speaker 1: I was really worried I was going to go along on this, so fortunately I did not. I want to 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 I am here reaching out. We have uh engineering openings, but we also have a lot of volunteers 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 more less for volunteering to help me figure this out. If you want to 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 want to get faces that look like their students' faces so that they can have somebody
Speaker 1: 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 that's the end of my slide. So I have time for questions. I don't know what you'd ask me though.
Speaker 2: Great talk, thank you. Uh my question is, if you were to do it all over again, knowing what you know now, how would you do it differently?
Speaker 1: Oh I I the the smart answer was I wouldn't do it. Um because I still have my full-time job writing curriculum and this takes just a lot of time. I don't I 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 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.
Speaker 3: You said you were a mi a middle school teacher originally? Awesome. Did you find uh as you were building this uh 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 uh were you able to use that experience?
Speaker 1: 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 just like randomly going down a rabbit hole because that's that's the mentality that I got into. So it 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 that this is the natural inclination is not to like 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
Speaker 4: Then it's time for the break, I believe, which is downstairs. A round of applause.
It gave writers consistent models and formatting, let them publish without engineering help, made global updates possible, and allowed the team to generate metadata-based views such as standards calendars.
Discussed at 8:09He used Django Reversion to keep version history and roll back changes, together with Reversion Compare to inspect differences. This made it possible to audit contributions from remote users and recover from bad changes.
Discussed at 12:00Use existing packages, start with a small and constrained version, and iterate rather than trying to build everything at once. He also recommends using the Django community and looking for instruction that explains the concepts, not just tutorials that provide steps.
Discussed at 12:46He would begin with the static version and keep the scope tightly constrained, avoiding many extra features until they were proven necessary. He says he probably would not change the basic incremental approach.
Discussed at 18:05Note: We understand that names change, people change, and bodies change. We respect each individual's journey and privacy. If you have any concerns about a video or need us to remove content, please don't hesitate to contact us. We will handle your request with care and promptly address any issues.
Published July 15, 2026
Published July 15, 2026
Published July 15, 2026
Published July 15, 2026
Published July 15, 2026
Published July 14, 2026