Debugging is a fascinating experience. On the one hand, it's the Jungian shadow of design, forcing you to look at everything that's wrong and unintended and resistant to conscious control in your work. On the other hand, there's the thrill of the chase. I really started to enjoy debugging when it dawned on me that it always ends in a surprise. That follows trivially from the definition: if you knew what the problem was, you wouldn't be hunting for it. But experientially the surprises are often rather dramatic -- as if there's a built-in Agatha Christie plot generator -- and can be quite enjoyable as long as one's genius ego knows how to take a punch.
I concur with this thought. For me, the act of debugging is an act of pure problem solving, even more so than the act of programming. Why the hell is this code acting this way rather than the expected way? And what is the right way to fix it? Oftentimes, programming can be (almost) reduced to pasting together libraries and putting a nice UI on the resulting code[1], but debugging is always a fresh experience.
[1] Of course, I know this is a total oversimplification.
Your comment reminds me of another thought I've had, which is that debugging is the part of programming that's closest to empirical science. You're faced with a piece of reality (a running system) and you don't know how it works.
I came here to say something similar. I just finished teaching programming to complete beginners, and getting them to actively debug was one of my hardest tasks. His comment about programming without being able to debug is programming blind is spot on.
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.
What I find fascinating is that problem solving seems to be so counter-intuitive for some people when to me it just seems natural and obvious. Like you said, "I suppose I had to figure [it] out on my own." I'm the same way; nobody taught me.
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.
I get this a lot when talking to semi technical people about a project I'm working on. Their side of the conversation normally goes something like "Well how did you think of X? But where did Y come from?", to which I reply, I wanted X, X needed Y to work, so I created Y".
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?
This could be the best on the subject I've read. But I wish he spent a sentence fragment mentioning sources (like Papert's Mindstorms) which expand on how important an activity debugging is. Some people think that a real innovation of computing is that there's now a word for "debugging".
> "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."
How to be a programmer, step one: if you publish an HTML document, please get your encoding right. (No `Content-Type: text/html; charset=UTF-8` for latin-1 documents.)
Why doesn't the PDF have hyperlinks, but the HTML does? It seems this is an epidemic for PDF versions of text also available as HTML. Is it really so hard to make a PDF that has them?
I haven't read the book but the table of content looks almost perfect. I wish I had something like this to preserve my sanity when I first entered the industry.
you're damn right it's long and between all the "how to be a programmer" guides that pop up on HN (all of which are usually 10 point lists that I can only equate to CS masturbation)THIS ONE, this one really long guide here, is worth printing out and reading in it's entirety.
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).
Yea, let's be honest. Most of these "how to X" books should really be condensed into something like this. We should be thankful the author was considerate with our time and wise with his words.
Yes it looks long, but for what I have been able to read so far (the first couple of chapters) its a worthwhile read. The programmer inside me is afraid that if I don't read it before I sleep I will never be able to find it again!
