Mike Hewner's Homepage

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.

So today I taught a database class in the Rapid Prototyping course I normally TA. This class is three hours long and when the schedule calls for a lecture it is brutal. This being my second time at the podium, I was somewhat prepared. I structured the class into lectures interspersed with various activities: a semi-multiple choice worksheet thing, some group work on a DB schema design, a fairly long section of independent/group coding on some SQL challenges, and then a live coding section with me at the helm (and them, at least in theory, coding along with me).

Overall, I think the lecture was good although my jokes fell sort of flat. I’m not sure if it was me, or the time in the semester, or what. I think I need to work harder at the onset to establish that there will be jokes, so that people know it’s OK to laugh. As it is, I worry they may be a little stunned and not sure what’s humor and what’s not sometimes. With activities, jokes aren’t as necessary to keep people conscious, but I’d still like to integrate them better into my style.

I think the activities worked well to break up the lecture and as usual they got almost universal positive feedback. I actually asked the students to install software (RazorSQL) on their laptops before class: I was actually gratified to see almost everyone did. It made me think that large scale coding exercises can really work, which is good news because I think it’s easy to let syntax wash over you if you don’t have to fight the compiler and think about it carefully.

As part of my prep for the class, I built a demo app. Basically we talked about 4 different ways to store data (flat file, pickle, XML, and DB) and I wanted them to have example code for each of them, even though we really only went into detail on the DB code. I’m not sure the time I put into that app was well spent; I really underestimated how long it would take to get it written. I sort of hope Keith uses it next year because I think it is a neat reference, even if we really don’t have time to walk students through it. The detailed work I had to do building the database part of it was extremely valuable though; I was able to discover all sorts of funky bugs and discuss them in class.

Stuff: