The Becker Blog

I just read Mark Guzdial’s excellent post on some of what’s wrong with how we teach introductory programming courses.

Question Everything: How We Teach Intro CS is Wrong

The notion that we should be modeling expert behaviour when teaching programming is silly. Experts work quite differently from novices. We accept this as a given in sport – if you make a novice do things an expert does you could very well cause them to injure themselves.

I have taught introductory programming on & off for about 30 years and have never really been happy with the way we do it. Mark puts his finger on at least some of the reasons why. We make novices write their own programs WAY too soon. We also don’t provide enough variety.

This probably sounds redundant, but we should be helping students (novices) become experts by starting off teaching them how to be novices. In my experience most intro programming instructors “teach” by lecturing, going over one or two examples, telling them to read from the book, and making students do a few assignments.

I certainly agree with the idea that we should be using a wide range of approaches. Most of the time, we use a very few.

Here are some of the ones mentioned in Mark’s post and in Alan Fekete’s comment :

1. Write a program to do ‘X’.
2. Fix this program.
3. Document this program.
4. Trace a program.
5. Explain a program.
6. Identify differences between two programs.
7. Convert pseudocode into a program.
8. Teach someone else about this feature of programming.

One of the ones we really don’t use often enough is the “change a program” exercise. I don’t know about anyone else but that is my own main method for learning a new language on my own. I *never* use the approach we impose on our novices myself. When I am trying to learn a new language, it is usually because I have some thing I need to accomplish. So I look for existing code that does something similar – usually several examples. I check them over to find the one that is closest to what I want AND that makes the most sense to me (we all have different approaches to coding) and then I try and modify it to fit my needs.
If I were to organize these notions into some rough hierarchy, I’d do “change a program” before asking them to “fix a program”. I think debugging requires a relatively deep understanding of the way the code works. I think we use this approach way too early. I have been guilty of that myself – recently – and your post Mark has helped me to get a handle on why that approach rarely works well with rank novices.

I also think one of the strongest reasons why intro programming is often taught the way it is is because we’re lazy: creating 12 examples is more work than creating 2 or 3, so if it’s not in the book, we’re not likely to make it up ourselves.

There are, of course, many exceptional CS teachers who do make up their own examples and who create resources for their students, but this is not the norm. Even those who DO make up their own examples typically just make one or two to ’supplement’ the text. Here I will fess up and say I am one of those who made up a few of my own examples and then used those year after year.

p.s. I also maintain that laziness is an essential quality in a computer scientist: why else would we work SO hard to find an easy way to do things?