I’m writing this on a plane back from Toronto, where I spent a few days teaching librarians to code as part of the Mozilla Foundation’s Software Carpentry program (which was basically the funnest thing ever, and Mozillans are smart and nice, and Toronto makes a spectacular case for itself, and Canadian librarians are 100% high-grade awesome).
Teaching this clarified for me some of the difficulties I had with my online Python course (where by “clarified” I meant “I sat bolt upright at 3am wondering why I hadn’t realized this before and had to spend the next hour writing it all down and trying to figure out how to get back to sleep”). So let me try to put that into words — but first I need to back up and explain an important paradigm I have for understanding the programming learning curve.
I believe, from personal experience and talking to people at different places on the programming learning curve, that the kinds of problems you are engaged with fundamentally change with every order of magnitude of the size of program you write. (Yes, lines-of-code is a bad metric, but it’s a good ballpark, so let’s roll with it.) They’re all important, complex, meaningful problems (though it can be hard to remember that you ever needed to solve them when you get too many orders of magnitude past them). They go roughly thus:
- 0 → 1 line. “What the heck is this?!” What is a programming language; if applicable, how does it differ from other related things you may be familiar with, like markup languages or Excel formulae; what do “function” and “control flow” mean and why do you care.
- 1 → 10 lines. “How can I do something useful with a programming language?” And by “something”, I mean one atomic task, but one that runs from beginning to end with correct syntax and employs those fundamental conceptual building blocks.
- 10 → 100 lines. “How do I break a task down into subtasks?” Modularity, reuse, DRYness, planning.
I’m not going to articulate the next few orders of magnitude, both because they are not relevant to beginner or intermediate programmers, and because I’m climbing the 1K → 10K transition myself, so I’m not able to articulate it well. But they have to do with elegance, abstraction, performance, scalability, collaboration, best practices, code as craft.
The 3am realization is that many, many “introduction” to programming materials start at the 1 → 10 transition. But learners start at the 0 → 1 transition — and a 10-line program has the approachability of Everest at that point.
This is why the CodingBat exercises that Boston Python Workshop developed are such a big deal. From this side of the 0 → 1 transition they look meaningless — they’re functions, with the
def function_name() part already written, that require you to write, in many cases, one line of code to accomplish the goal. One. Line. And they’re not meaningless at all. They’re where students discover what they did and didn’t understand from readings and lectures and messing around with the shell. They’re where students discover that they may have vocabulary and syntax, but they don’t yet have a conceptual model of what a function is. And in practicing writing one-line functions, they develop that conceptual model. It’s absolutely critical.
And this is going to be the next big thing I struggle with in teaching this better. Because the fact is, you want to be teaching examples that are grounded in real-world tasks. They’re motivational; they’re more comprehensible than abstract examples; they make it easier for students to connect course material to their actual work, meaning they’re more likely to be able to keep using it, to climb more of the learning curve on their own — to get to a place they can actually use this stuff, which is not a place you can get people in a day or two.
But I don’t know how to do a real-world task as a one-line function. I know how to write a ten-line function that does something real-world-useful, and how to walk students through discussing it and modifying it. And that is great for the students who have already climbed the 0 → 1 learning curve. But it’s baffling for the ones who haven’t.
I think I can do this, with thoughtfully chosen examples. I think I can come up with one-line things that can be wound into ten-line things, so students leave a course with a working program that does a thing they can imagine using (or, at least, a working program that’s a close enough cousin to something useful that it suggests where to go next and gives them a head start in getting there). But this is going to be hard. This is totally, “I apologize for the length of this letter; I did not have time to make it shorter” territory. Simplicity is brutal. And one-day intensives, or four-week onlines, do not have time for unnecessary things.
At any rate. I came out of the last two days with this to mull over, plus a stack of books and articles of research on code pedagogy, plus a bunch of good memories and tasty food experiences and new people to follow on Twitter and face-to-face encounters with people previously followed, so it’s just made of win. But I welcome your thoughts.