To me one of the most important reasons for having third-party code be opensource is that when something's going wrong i can go into the third-party source code and litter it with pdb breaks.

I recently read these two books (from different decades, different publishers, different editors, with different interviewees, yet almost the same title and approach).
Highly recommend both - the former is like a snapshot of the early 80s, the latter is like traveling back in time gradually from the 2000s back to the 1950s.

The same observation re. debuggers was true there - most of those guys relied on print statements, and rarely debuggers. At least one, I forget who, even talked about printing entire programs on paper, surrounding himself on the floor with paper, and spending a few days reading it like that until he understood everything more or less fully.

There was also a nearly unanimous nostalgia for the days when it was possible for one person to understand almost literally everything about one computer, and general dismay at the "boring" nature of much of modern programming: making huge systems mostly by gluing together libraries.

Me, I practically live in pdb.

(oh, and re. Programmers at Work, it's now online: https://programmersatwork.wordpress.com/)

I've just been having this debate with work colleagues. In a team, I'm usually the *only* person to use a debugger. Non-debugger advocates are usually as mystified at me as I am at them. The usual objection is that "using a debugger is no replacement for reading the code".

In fact, most of the time, I just use a debugger as an interactive print statement, not for stepping through code.

However, stepping through code is more or less the only way I can quickly get a grasp of complex, third-party software. If I attempt it purely through reading, I have to carry an entire call stack plus a bunch of example variables in my head, and I have to do that at the same time as finding, opening and flipping source code files. That's just about possible for me when a project has up to say 15 modules (at a stretch), but beyond that, I need help.

So, I think these people must simply have much better memories than me (this is almost certainly the case -- my casual memory for immediate facts is appalling).

Either that, or they (a) aren't having to support big frameworks that other people have written, and (b) don't, in the course of their work, need to understand critical paths through code *quickly*. My bet is on the memory point, though. I would be interested to see if there's a correlation between casual memory recall ability and debugger use :) What's your memory like, Chris?

Bertrand Russell? Principia Mathematica, pacifism, possible "turtles all the way down" guy?

@wade: whoops, fixed! meyer! meyer!

@seb: my memory is very poor. i'd tend to agree with what you said.

I get especially worried about programmers who've *never* used a debugger for their language, as opposed to those who usually use logging or some other method. It may well be that it's faster or easier for you to use logging most of the time, but if you've never tried a debugger tool, you're very unlikely to pick it up in the cases when it could save you time.

What I don't understand about the guys who never use debuggers is: How do you know ahead of time everything you're going to want to inspect?

To me the exploratory feature of debuggers is key. When I'm first starting to diagnose an issue, I may have an idea what I'm looking for - but that first idea is often wrong. It's so quick to just drop into the debugger, confirm or deny my first suspicion, then start sanity-checking everything around, maybe step up to the parent frame to sanity-check the enviroment there, etc.