The end of the quarter is coming fast, and one of the side effects is that the material we’re covering is more complex. The second-quarter Python class and the accelerated Python class focus on applications of inheritance and recursion near the end, and writing HTML parsers and web crawlers isn’t trivial. My usual trick of asking relatively easy questions of the class to encourage participation tends to stop working during times like this. Unfortunately, that’s exactly when I need the most participation, which can make for frustrating classes.
As it happens, yesterday I stumbled on a trick that seems to help. My accelerated students were struggling a bit with their first HTML parser, so I asked them to give me code that didn’t work. I told the students who had solved the problem that they could reply too, but they had to add a least one bug in their code first. In various rounds of this both students who I knew were adding bugs (I peeked at their screens before I called time) and students who were dictating their flawed code responded. I would run the flawed code and then asked for multiple rounds of edits from the students. Everyone could only suggest a single edit, and we would see if that edit improved things before moving to the next edit. It worked beautifully, both because we were seeing how one might take a flawed parser and improve it, and because the situation helped to eliminate the stigma of not giving the right answer.
I plan to solicit flawed code more often from now on, and not just during tough coding times. Seeing bad code and seeing how to improve that code is a freeing and instructive thing for my students. I only wish I’d thought of it sooner.