Teaching is hard. The first time I sat down in front of a room full of undergraduates and found myself tasked with communicating information to them, realizing I was largely responsible for their ability to understand the material, I was a little overwhelmed. How do you distill an entire discipline into a sequence of lectures, exercises, and discussions?
Writing courses for Codecademy is very much like teaching a class. You have to figure out the best way to explain technical terms and concepts, the best order in which to present information, and how best to divide the work into digestible pieces—exercises, sections, and courses. When writing my own Codecademy courses, I usually go about it in five steps.
1. Big-picture planning
Teaching a programming language is similar to teaching a natural language like German or Mandarin. The early exercises shouldn’t assume any special knowledge, and later exercises should build on previous ones and give students the opportunity to use what they’ve learned.
I’ve found that it’s tremendously helpful to understand the “big picture” aspect of each course that I write—what material to cover, useful analogies and comparisons, and so on. Beyond that, though, I make a conscious effort to explain to students what a programming language is good for and what they’ll be learning in the future, both to keep them informed as well as motivated.
When writing your own courses, set yourself up with a word processor, pencil & paper, or dry erase board and map out the subject you want to teach. Resist the urge to teach too much too quickly! There can always be more exercises to expand and expound.
2. Small-picture planning
Once I know what topic I want to cover, I divide the course into sections and the sections into exercises. (I usually set up the outline of my course first, then fill in the content later). With practice, you’ll get a sense of scope: how much material to cover at which level. A lesson with 100 exercises covers too much; a lesson with 3 exercises, too little. The sweet spot seems to be five to seven sections, fifteen to thirty-five exercises.
3. Exercise and default code creation
Once my outline is complete and I’m comfortable with the amount of information and the order in which I’m presenting it, I start writing exercises, one at a time. I don’t always go in order (see #5), but I do my best to ensure that I don’t introduce anything new without thoroughly explaining it. If I mention something I’ve covered in a previous lesson, I try to link back to it or provide a reminder in the hint.
I don’t usually worry about SCT (Submissions Correctness Test) creation at this point—my concern is writing readable instructions and good default code.
4. SCT building
This is the part I spend the most time on. A Codecademy lesson is only as good as its weakest SCT, and it’s very easy to write overly simple (or even broken!) SCTs if you’re not careful. The best SCTs identify the correct answer, rule out any incorrect answers, and provide useful error messages for common mistakes. For example, let’s say you want a student studying Python to write
p = ‘spam'
in the editor. Your SCT could just be return codecademy_lib.printed(‘p’), but this won’t check to make sure the student actually accessed the second letter of the string by offset; they might have just put print ‘p’ in the editor and called it a day. A more robust SCT would be:
if type(error) == IndexError: print “Oops! You went too far. Use a smaller number in !” return False
elif not codecademy_lib.printed(‘p’): print “Looks like you didn’t get ‘p’! Did you start counting with 0?” return False
else: return codecademy_lib.printed(‘p’) and ‘[‘ in code
This makes sure that the student didn’t cheat by just printing “p,” while also providing helpful error messages along the way.
I always go through my SCTs as part of my overall run-through (see #5) to make sure I haven’t updated code or instructions without also updating the SCT.
5. Overall run-through
Finally, I run through my course in preview mode, exercise-by-exercise, and then in overall view mode in order to ensure that:
I haven’t introduced any information out of order;
I haven’t updated code without also updating comments, hints, SCTs, and instructional text (the most common error I run into is changing variable names in one place and not everywhere else);
I haven’t written a broken or inaccurate SCT.
If I can run through my entire course twice, providing correct and incorrect answers, without hitting a bug, typo, or inconsistency, I submit the course for review.
And that’s it! I hope some of this was helpful to you—I know it’s been a bit of a learning process for me. Good luck with your course creation, and happy coding!
Please note that a guest post is from a member of the community and not the Codecademy staff.