Over a few weeks, I taught a group of 6 teenagers, complete beginners, how to program using Python as the main language to illustrate concepts and to code examples. There were 4 sessions lasting 3 hours each. The final session was about 3 weeks ago and since then I've been trying to tie all the little bits of knowledge and experience from this into a neat knot, to extract some lessons learnt and do better next time.
I probably waited a bit too long... At the same time perhaps this is giving me some much needed perspective. I've had many discussions about the whole thing, mostly the parts where I feel I failed because they tend to shine the loudest in my mind :) But writing the introduction to this blog post I realised, "4 sessions," well, perhaps I need to cut myself some slack as well.
Problem: Outline
From the very beginning of the course, it was clear and obvious that I had a hell of a lot to learn in scheduling and outlining my lessons, as my ideas of how much we could accomplish in one session were widly, widly, wiiiidly off. I remember telling the course organiser before the first session started, "I'm sorry, do you have a backup to keep them busy for the final hour in case I don't have enough material?", convinced that it would be hard to last more than 2 hours with what I had.
In the end it took about 10 hours (out of a 12 hours course) to go through the material I had put together for this first session. Heh!
I was hoping we would have time to do some fun stuff with pygame notably, because I think graphics feel more rewarding to code, especially when you're young as it's easier to show off to your family and friends what you've been up to. I'm not giving up on finding a way to put this together for the next course I will be teaching to teenagers, maybe next September (to be confirmed!)
Problem: Knowing how to program vs. thinking like a programmer
The stingiest disappointment for me (and thus the one that's been on my mind the most since then) was the very last session. For once I had actually planned my time more or less correctly: first we would see how to read and write to a file, then for the final 2 hours there would be a cool exercise building up on everything we'd seen so far: a simple rot13 encryption/decryption program, where the encryption program asks for input, encrypts it and writes it to a file ; while the decryption would be about reading the file and decrypting it back.
That was a catastrophe. Although the students had always managed to make their way through the one or two-liner exercises with varying amount of sweating depending on the concept at hand, they just didn't know where to start, or what to do next after I gave them a few clues and the beginning of a solution. About halfway through this it dawned on me that although I had taught them how to program, I hadn't taught them how to think like programmers. They were unable to decompose the problem into manageable steps that they knew how to solve.
That's absolutely my failure of course, that day I left the room very discouraged and wondering whether it was worthwhile for me to pursue this again. After a few nights of sleep, hell yeah, I'm motivated to learn from my mistakes and make new ones until I figure out the whole thing. Speaking with Laura at OSS BarCamp was quite encouraging as well ; she's organised many (most!) awesome open-source events in Ireland and yet, told me that she still gets some things wrong. I also started looking at some MIT Open CourseWare courses on education, going through some of the material and getting interesting book references ('How people learn' looks awesome!) I want to parse and digest as much research on education as I can, understand better how learning works and what teaching methods are effective and in the end, keep the bits that matter to what I'm doing.
Improvements for next time
Regarding the schedule and outlining the course, I think it will take experience for me to get it righter. I now know to take it easy, allow lots of time for new concepts from the very beginning, prepare exercises at different levels to keep the students that get it faster busy. I'll be teaching version 0.2 of that course to adults starting next month, and I'm wondering whether I should assume that the pace will be a bit faster. I don't think that grown-ups are more intelligent, or have more aptitude than a bunch of 15 year old. What I suspect is that when you make the time in the midst of all your other grown-up responsibilities and time commitments, to take a course and possibly even cash out money for it, you're more focused and motivated to learn. While teenagers might not perceive learning with as much awareness, when they're likely doing an activity because it's been organised for them or they had to pick an option to fill their timetable. I'm not sure whether or how that will impact the pace of the course (any thoughts?), but I will try to allow for that.
With regard to learning to think like a programmer, I think I will try to include more reading of code particularly when introducing new concepts, perhaps even writing them as pseudo-code to not distract with the syntax and language quirks. What I mainly did this time was introduce 2 or 3 liner toy examples, then building on them, with the students writing the program at the same time as I do. It sounds straightforward but it isn't necessarily, as they haven't trained themselves yet to watch for stray whitespace or missing colons. It's a good way of getting in the habit of watching out for your indentation and other silly programming traps. And by the end they were getting used to it indeed :) But still, reading as in taking the time to think about what you're doing and how you are going to achieve the next step was sorely missing. I want to include sections where we go through existing small programs to understand their logic, and I want to go through small problems and show how to decompose them into smaller problems. To be honest, not doing that last one was perhaps a bit of a cop-out. It's easier to give exercises and help people as they encounter difficulties, rather than talk to a room of distracted students who usually don't give any feedback on whether things make any sense or if they are even listening :) I will work on that.
Feedback
In the end, while it's clear that the course wasn't perfect and I have much to learn and improve on, it certainly wasn't all bad. Before we started on the ill-fated rot13 exercise, I gave the students a feedback form on the course and got 3.5 data points out of it (a kid was sick, another was missing, and one kid filled in half the form about a different activity that was occurring in parallel). (Side-note: I'm learning to create feedback forms on the fly, but I think if you're going for qualitative rather than quantitative, easy to aggregate data I heartily recommend the "3 words to describe the course/training/whatever" approach. It's a great way to get people's overall impression and feelings on the course. Keeping in mind that if the forms aren't anonymous, people are less likely to be honest about negative aspects.) The students were generally happy about the course, with words like "worthwhile" and "cool" coming up often, about as often as "hard" ;) So it was difficult but they got something out of it, and didn't feel like they were wasting their time. I didn't turn anybody completely off programming, which was a major fear of mine when starting this (victory!)
Onward to becoming a better teacher!