I think that this article is right on target in that we need to do a better job in teaching so that students understand the _why_ and not just the how. I have always been frustrated in classes where I am taught a technique for doing something, but don't understand where it is and isn't appropriate to put into practice. I ran into that issue in my Physics class a lot, where I knew how to found say the length of a vector, but didn't know when it was appropriate to do so to solve a larger problem.

The thoughtful programs that we are writing will hopefully help us in this process. In addition, the design homeoork can also help. I would say that this rule would also apply to debugging. I would want the students to understand why I'm looking for something in this class as opposed to another, the process that I'm using, etc.

While the article focusses on teaching procedural programming, and I think using terms that are more complicated than necessary, the ideas that he presents are right up my alley, and I hope that we are able to bring some of that to our future classes.

MY COMMENTS: Matt brought up a point that I've often wondered about: how much do students depend on TA's to debug their code? I see a lot of people going up to TA hours because they can't "find a null pointer exception." Should the TA's really have to go through these people's code? In some cases, I think so. In adventure, my keys didn't work because I called this.start() instead of this.Start(). I had no idea why they didn't work. I traced through all the code, put in printlns, etc, but couldn't find the error. Some other people, however, came to hours complaining that the support code was broken, and the TA's ended up searching through their code to find the bug. I don't think that TA's should be a substitute for debugging, and I feel they are becoming just that.

(In reaction to Matt A.) One thing to keep in mind, though, is that debugging is an acquired skill, just like every other part of programming. We tell students to look at where it crashed, and figure out why the reference there is null, or we tell students to put printlns in their code. However, knowing where to put printlns to give you useful debugging information (rather than just filling your screen up with useless output) is a skill which must be learned. For a lot of students, they just do not know where to start when trying to find a bug. At that point, the TA should sit down with the student and show them how they can hunt down that bug, rather than just looking through their code and telling them the line which is wrong. Like many things, this is a time-consuming process which is not always possible with a 20 person waitlist, but in an ideal world...