Of course, I know this is a total oversimplification.
When most of my students' code wouldn't work, they were blind. I had to teach them both the questions they had to ask themselves and how to answer those questions. There's a logical process involved that's similar to induction that I suppose I had to figure out on my own.
Teaching that process was the hardest thing to do, no question. I said many times during the course that algorithmic thinking will be a kind of thinking that's completely new to them. What I hadn't anticipated was that the thinking required for debugging is actually a level above that.
That you'd have to teach someone that when something goes wrong the first step is to narrow down the possibilities until you find the cause baffles me, but I've had the experience of leading people through that process so many times that I no longer think they're just being obtuse or lazy. It really must be a learned skill.
The question is always asked, and the answers are always similar and I always feel awkward explaining things that are second nature. It's akin to someone asking - so why did you exhale?
> "Surely 'debugging strategies' were developed by successful learners long before computers existed. But thinking about learning by analogy with developing a program is a powerful and accessible way to get started on becoming more articulate about one's debugging strategies and more deliberate about improving them."
That's a classic line, and too true.
(serious question, actually. I've never tried.)
Include that package in your Latex document, and it automatically makes all section references internal-links. It's great, and too few people use it.
-- just another Shootin' Fightin' Dynamitin' Mining Engineer
the reason it keeps showing up on HN is for new users, like yourself, to read about it.
if HN had a "best of the best" based on re submissions and up-votes, this would be on that list (also, erlang).