One of the things that make Computer Science education difficult, at least in my opinion, is that students often blunder into some tricky topic you haven’t addressed. Of course, this is part of the ordinary practice of programming…discovering something is more complex than you envisioned, understanding the problem, searching around till you find a fix. Sometimes, I think it might be educationally useful to let students flail a bit and learn how things work. But just as often, I think students can stray into something that is going to be too difficult to work through on their own. It’s very important to me that a student not spend two unproductive hours fighting with something that I (as a teacher) know they will never get success with.

In the Rapid Prototyping course I worked with, this seemed to come up a lot. I think part of it was using Jython, a language with not a lot of sample code out there or clear beginner level tutorials. But also, because I was in the privileged position as a TA, students would come to me with their problems so I knew what was going on. Being at least somewhat experienced, I could tell when problems arose that were educationally unproductive (I think usual undergraduate TAs tend to assume that every hellish experience they endured as a student was some sort of intended character building exercise).

I wrote up a few of these common problems into documents. I usually included explanatory text and sample code: this was a tough decision. I know students have a tendency to just cut and paste code snippets, but without the code it just seemed extremely vague. In the end, considering that these issues were usually secondary to the actual intents of the class lessons, I opted for code on the theory that getting the students back on track was more important than ensuring that they truly understood all the issues I brought up in these documents.

If you’re curious, feel free to check out the documents I wrote for the rapid prototyping classes.