Would You Like a Hint?

Students ask me why their program doesn’t work all the time. Sometimes they ask me as soon as a problem pops up. Usually they work on it themselves for a while. They also ask their peers for help. But sooner or later a lot of problems come to the teacher. This is where things get tricky.

Obviously just giving them the full answer is generally not the best idea. Students learn best when they figure things out for themselves. On the other hand the frustration level can rise high and fast at times. A teacher doesn’t want things to get to the point where a student gives up. So timing is the first complication. That can be very dependent on the student and the relationship they have with the subject.

Figuring out the problem yourself is a bit part of the problem. Often the student has not paid attention to the messages the system has given them. “What error message are you seeing?” tends to be my first question. Next it to ask the student what they think the message means. Sometimes that is enough to get them over the hump with the problem. It’s important to get students used to reading and understanding error messages. There is usually enough of a hint there for many problems. Sometimes the student doesn’t understand the message. This is often an opportunity to explain the words in the message and how they apply to the statement in question. Learning to read error message is a critical skill.

Student problems, like most programming problems , tend to fall into two categories – syntax errors and logic errors. This is where teacher experience really comes into play. An experienced teacher can usually figure things out quickly. Though occasionally a student manages to create a problem I have trouble with. This is actually a good thing because it gives me a chance to model debugging techniques. That is a sort of hint for students in and of itself.

The next complication is how much of a hint to give and how to word it. For example yesterday I had a student who was trying to compare a string variable to a constant. In C# string constants are enclosed in double quotes while char constants are enclosed in single quotes. The student was using single quotes. Several hint possibilities come to mind. One can simply say “Use double quotes in place of single quotes” that that will fix the problem. It doesn’t help the student to understand what they did wrong. Another option, which I took in this case, is to say “you can’t compare strings to chars in that way.”

With that hint the student still had to figure out what is a char in his statement and also how to fix things. This student was able to talk himself though the issue and look at the problem in several ways. A more experienced student would have seen the problem sooner. Of course this student is now more experienced than he was before and will probably spot this sort of problem quickly in the future.

Hints are not always easy though. There is a temptation to tell the student too much. At least for me there is. For others the temptation is to give too little a hint. It’s a balance. There are researchers working on developing automated hinting systems. It’s a wonderful idea but a difficult problem. One limitation I think they will have is customizing the hints to the student. I think most systems will start with tiny hints and more up to more complete hints as the student progresses (or not). That will probably work for most students. What do you think?

For the time being it is up to the teacher. Hinting is one reason I think we still need computer science teachers for most students.