We're all heard it from students "My code is the same as yours but mine doesn't work." The implication is clear – it is the computer's fault that the program doesn't work. Of course something is always different.
Often times it is a small difference. A student confused and lowercase l for a 1 perhaps. Or the is an extra or a missing semi colon. Sometimes the problem is in related code that the student hasn’t though to check. One thing I see a lot of is students referencing form objects (a button or a textbox) that they didn’t name the same way I did. Trying to reference txtName.Next as my code does will not work correctly if their textbox is still named textBox1.
Computers are picky that way. Names matter, semi colons matter, and many other little details that our minds easily fill in for us are not obvious at all to the compiler. Nor are they obvious to students. Students rush. They take shortcuts. They are used to things working out. Computers don’t work that way. Sometimes I think the hardest thing about learning to program is to understand that details matter and that sometimes you have to look in less obvious places.
Students are used to quick fixes though. The TV murder is solved in 60 minutes (45 minutes plus commercials). The family crises is solved in 30 minutes on TV. Real life is not like that and programming is real life. I hear over and over again that research doesn’t support the idea that teaching programming automatically teaches problem solving. I have to wonder though if at some point debugging doesn’t click into the idea that details matter and that you need to look beyond the obvious answers.
3 comments:
Here is a new one for me. Working in VB. I gave the kids a printout of the code because I wanted them to build a form just to get familiar with the interface. Here is what I expected - build the form, double click the one button on the new form, type in the code from the sheet of paper. Here is what happened. Type in the code, build the form. Since I did not see the student do this I could not figure what they did to get the really cool errors that came up. (I do not work in VB regularly.) After a brief interrogation we got it figured out. The kids are always finding new ways to make me think.
Garth, my students are also coming up with new ways to make me think. The order in which things happens also make a difference that students are not always aware of. On the plus side we keep learning more ways to do things wrong. :-)
Ha ha! During my years teaching with the Adobe Creative Suite, I always contended that teachers know the tools better than many professionals because we've had to figure out how 200 different users mistakenly did something with it.
In CS, I've been amazed that students still keep finding innovative ways of solving assignments. (They aren't all correct, and are usually inefficient, but that's ok in the beginning.)
Post a Comment