What does “doesn’t work” mean?

Every computer science teacher has heard it “My program doesn’t work. What is wrong with it?” Sometimes they will show you the code without any more explanation than “it doesn’t work.”  One generally replies with something like “define ‘doesn’t work.’” Or you are told the program is giving an error. When you ask “what error?” you get a blank stare. The student has shut the error message away without reading it. Somehow you, the teacher, are supposed to know the answer without really knowing the question.

Debugging seems to be the hardest thing to teach students. To be fair, debugging is hard. One quote on my bulletin board is:

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”

- Brian Kernighan

There are a few good, and easy, places to start though. One of them is actually reading the error message. For some reason that doesn’t seem to occur to many students. Of course they often don’t read the directions either so I probably shouldn’t be surprised.

Giving some serious thought to the error message is often enough. To be fair, I like to be fair, some error messages are less than helpful. Helping students to understand the error message is better in the long term than just telling the student what they did wrong. Why do you think the computer doesn’t think that variable exists? Did you spell it right? Did you declare it in the wrong place? Remember when we talked about scope?

Another helpful technique is to explain what the program is supposed to do, how it is going wrong, and how you think the code is executing. Many teachers use the rubber duck scheme and ask students to explain all of this to the duck. This works for some people and some errors. I don’t have a classroom set of ducks but do have students explain that to peers. Sometimes that is enough. Sometimes it is not.

When they explain things to me I often prompt with questions. Often students are wrong in their explanations. I remember one student telling me that of course the code did something because here it was in the comments. There was no code to execute what the comment described but the student thought the compiler actually read the comments. Sigh.

In all cases it starts with knowing what should be happening and what is or is not happening. The more detailed one can explain that the easier debugging becomes.