How to be a Programmer

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.

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."

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.

Yep, this was my immediate thought too. The number of new employees I have to drill in the basics of debugging and problem solving is frustrating.

way to be pedantic. maybe you should read some of those sections about communication.

It's trivial if you know how to do it: http://www.tug.org/applications/hyperref/manual.html

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.

In the HTML version the 2 is superscripted and links to a footnote. Must've been converted to pdf incorrectly.

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).

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!