Blogging about teaching: the intro courses

The story of how I teach intro courses has to start with my own first experience with a programming class in college. In short, it was a complete disaster. Now, I was not a complete newbie--I had taken a few computer courses in junior high and in high school, although none on the "serious programming content" or AP level, so I at least knew a bit about how computer programs worked. And for the first few weeks, everything was fine. But about halfway through the class, we were introduced to a concept--and I don't even remember exactly what it was anymore--that I just could not understand. Unfortunately, programming courses build heavily on previous material, and so this pretty much sealed my doom. Also, the class picks up steam and more material is covered in the second half, so I quickly found myself drowning. On top of everything, the professor was one of those brilliant types that have no business teaching undergrads (i.e., couldn't teach you if you weren't already a programming genius), the TA spoke little English, and I was intimidated by the fact that all of my classmates either (a) seemed to get things much faster than I did, or (b) cheated their way through the class. By some miracle, I got a B in the class--to this day, I have no idea how I pulled it off. But the damage was done: I now *hated* programming, an activity that had only brought me joy in the past.

This experience, more than any other experience I had as an undergrad, colors the way I approach teaching. My number one goal in teaching intro courses is to make sure that my students' first experience with programming is overwhelmingly positive (or as positive as possible). I remember the despair I felt, and I keep that in mind as I introduce concepts, make up homeworks, and talk to my students in class and in office hours. I try to make sure that my interactions with students, and what I do in the classroom, encourages them rather than discourages them.

The first programming course is probably the toughest course to teach. In any given intro class, my student population consists of the following groups (and yes, there is overlap):

* Potential CS majors.
* Students from other majors that are strongly encouraged to take a programming course--typically, math and science majors.
* Students who are taking this just to try it out, because it's different or because a friend recommended it to them, or because they need a math/science class to graduate and this class doesn't have a lab.
* Students who have never programmed before.
* Students who've done a little programming, or hacked their calculators, or something.
* Students who really should be in the next class up, but want to take an "easy" class for credit.

In other words, the students are all over the map in terms of skills and motivation. They all have different expectations. Some of them will never take another CS class. For others, this is the class that will prepare them for the classes to follow. Still others may come in with no expectations but may leave intending to become majors, discovering a passion they didn't know they had for computers.

The biggest challenges I have at this level are (a) maintaining everyone's interest in the material, without losing or boring anyone along the way; (b) making sure that the lesser-prepared students aren't intimidated by the blowhards (many of whom really have sub-standard skills, but they know the lingo and they know how to sling it around); (c) introducing an overwhelming number of concepts in the first several weeks, and making sense out of them; (d) making sure that at the end of the class, everyone has some baseline skill in programming a computer.

One strategy that's really helped for (a) and (b) is "pair programming", which basically means that everyone programs with a partner and each person in the pair splits computer time 50-50. (So one person might be typing and the other feeding her lines or debugging; I've seen pairs go so far as to have one person operating the mouse and the other operating the keyboard!) At the beginning, I take a survey and pair less-experienced students with more-experienced students (and separate the serious blowhards from everyone else). I switch up the pairs throughout the class so that everyone gets to work with different people. This works wonders in several ways. One, the students see that the other students come in with a range of backgrounds and experiences. Two, they see that *everyone* can contribute, even if they "don't know anything" about programming (their words). And finally, I get the more experienced students--the blowhards--on my side: they are "helping" me with the class, "helping" bring their classmates up to speed. Surprisingly, this more often than not works wonders with potential problem students.

(c) is trickier, and so I often pull out the analogy on the first day of class that learning to program is like learning an entirely new language with a completely foreign alphabet and syntax. You have to learn the concepts, but also the syntax and the grammar of the programming language, and just like you can't learn Mandarin in a day, you're not going to completely understand programming in a day either. This doesn't completely remove the frustration from the students' experience in the class, but they do find it helpful when I remind them that this class is challenging by nature, and the fact that they're momentarily confused doesn't mean that they're stupid or not cut out to be CS majors. And I tell them up front that they may feel a bit out of sorts until a few weeks into the course, but that they *will* have that "a-ha!" moment at about that time, and then things will start to fall into place. (And with very few exceptions, this does happen.)

(d) gets more at the specifics of what I teach and how I approach things, topics which I will cover in part 2 of this blogging miniseries. (Particularly since the tone of this makes it seem like learning to program is all drudgery and frustration--it's not!)

Finally, I don't make a secret about my own foibles with programming. At some point during the class--sometimes on the first day, sometimes in the third week when the frustration is really setting in for some students--I talk about that first programming class, and how I almost didn't continue on, and about how I rediscovered my love for programming over time because I didn't give up. And often this is just what the students need to hear to encourage them to keep trying and keep learning.

technorati tag: teaching-carnival