Tuesday, January 17, 2006

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:

9 comments:

Ianqui said...

Gee, it would've been nice to have you as a teacher when I took Intro to C++. My teacher didn't even know C++. He knew C, but was learning C++ along with us. We never even got to the object-oriented part of C++.

I never took another programming course, and now I make Super G write code for me when I need it. Pathetic, especially considering that sometimes I do need code written.

pjm said...

Thanks for writing this—I have a meeting tomorrow for my second semester as a Comp 11 TA, and we start in on Monday. So this is all good stuff to have in mind. Hopefully we'll do better this spring than we did in the fall.

Baker said...
This comment has been removed by a blog administrator.
Jane said...

Ianqui, it's never too late to learn! :)

pjm, the intro course is definitely somewhat of a moving target--what works well one time doesn't work so well in the next iteration, or even on a different day. Glad I could give you some things to ponder!

Ukiah said...

At least you recongnise the mere facts of the work.
I have read som where about the targeted areas being different
anna@www.azerivista.com

PhD Mom said...

Thanks for writing this series. I am looking forward to teaching an intro class myself next year for the first time. Teaching seems to be overlooked very often in academic circles and I am grateful for any advice you can give!

The Unknown Professor said...

You have some great ideas. I often teach an introductory (required core) finance class for the College of Business, and a lot of the issues are the same- the range of skills, the competing needs (first class in the series vs. the only class they'll take), etc..

The team programming is one idea I'll definitely be porting over to my class. I think another goodie (I already do it, but it bears repetition) is to remind the class often that they'll find their way out of the confusion shortly. In a techie class, it's easy for the "weaker" students to get overwhelmed to the point of depresion. So, a bit of encouragement goes a long way.

Sometimes their difficulties come not from being clueless overall, but from missing one or two key points that feed into many other areas. Once they get those resolved, they often start firing on alll cylinders.

Jane said...

PhDMom, glad I could be of assistance! :) I wish we did talk about teaching more in this profession...especially what's happening at the entrance points to the major. Good luck next year!

Unknown Prof, you hit the nail on the head with your last point. Often it is that one connection that they haven't quite made yet that trips them up...and once they do make that connection, it's quite the epiphany!

sims blog said...

The team programming is one idea I'll definitely be porting over to my class. I think another goodie (I already do it, but it bears repetition) is to remind the class often that they'll find their way out of the confusion shortly. In a techie class, it's easy for the "weaker" students to get overwhelmed to the point of depresion. So, a bit of encouragement goes a long way. sims299@natureday.com