I suspect most if not every Computer Science teacher has had this conversation:
Student: Hey, I’m getting an error.
Teacher: What error are you getting?
Student: I don’t know.
Often they have dismissed the message without reading it. Even if they have it on the screen they may still not have looked at it. Why? I have no idea. So the teacher goes to the computer, looks at the message, and asks the student what it says. The student reads the message and then asks “what does it mean?”
Today I was thinking that maybe I should write up a longer explanation of the most common error and warning messages my students get. Will they read that document? Maybe. Maybe not. Ultimately though the problem is that they give up too soon. They don’t spend enough time reading the message and trying to determine what it means.
It’s not just a problem for beginners though. Years ago I was at a computer company supporting professional developers at a very technical company that built very sophisticated systems. One of the most common parts of my job at times was explaining error messages. Often I was explaining messages I had never seen before but was able to at least parse some meaning out of them.
Now it is easy to blame the people who write the error messages but many of them seem very clear to me. Is that because I have so much experience making errors? Perhaps but I don’t think so. More often, especially with beginners, one is so close to the code and so sure that it is right that is seems incongruent that there is an error message. Many is the time a student has told me “I am doing everything right and still getting an error message.”
In the long run, students can learn a lot from their errors. They can learn about the code obviously but perhaps more importantly they can learn the value of critical thinking and close reading. We as educators have to be careful about finding the thin line between giving clues and giving fast answers.
4 comments:
I recall an assignment that I gave once to try and head off this issue (and my frustrations). Each group of students were given an error message from the language that we were using. They then had to create a bulletin board display showing the message, three possible ways that the error could be generated, and then at least three suggestions for how to fix or avoid the error. It was actually a fun activity since some students were kings/queens of errors and others claimed to never have seen one! Today, an alternative would be to have students create a slide or two in a collaborative slide deck and make it a constant reference for students. Before they're allowed to ask you for help, they need to check out the collective wisdom of the class. And, hey, if they do solve it, why not add their solution.
On the other hand, there are another whole set of error messages that are worthy of banding your head against the wall.
Windows Errors - Exemption occurred in module XXX at address XXXX:XXXX
Mac Errors - Uh oh. Something bad happened
How do you ever solve those other than the standard reboot the computer and try again!
I have kids working in Visual Studio C# that cannot figure out the red squiggle under a line means there is something wrong. As teachers we hate to admit it but sometimes someone is just not smart enough to read and understand what they read. There are also those that are just to lazy to read. If I have a student that has been programming a while I simply say "Google it." Understanding error messages is part of learning to program but we cannot teach them the absolute meaning of every error message. They have to read. Then of course there are the error messages that give not a clue. Then you tell them to just start digging and start throwing in Print statements.
See our papers, e.g.:
http://cs.brown.edu/~sk/Publications/Papers/Published/mfk-measur-effect-error-msg-novice-sigcse/
Post a Comment