[WirelessGigabit]

I am a huge proponent of debuggers.

Being able to look at state step by step without having to stop, add log statements, recompile and go back are too slow (for me).

What concerns me more is that is that I end up working with contractors with 5+ years who don't know how to set up a debugger for the code they are working on.

And that concerns me. It's not OR logging OR debugging. It's both. You use the best tool for the job.

[ska]

It's definitely both. Ideally the debugger is never your first resort.

An extremely common failure mode for less experienced developers is messing about in a debugger all afternoon for a problem that should be solvable in 5 minutes. It's a very slow way to learn.

[fluoridation]

Weird, I've never run across that. I have wasted a lot of time rebuilding and retesting figuring out where to put a print statement and then figuring out what and how to print it, where a debugger would have let me turn breakpoints on or off and watch different variables in the same run, all without touching the code. I don't think I've ever thought "gee, this debugger sure is getting in my way! I wish I could do printf-debugging instead."

[ska]

The world isn't printf debugging or debugger only.

Some things are really amenable to the debugger, especially simple bugs. Really especially ones that should have been caught by static analysis anyway but that's a separate issue.

The issue is that firing up a debugger can easily become a fishing expedition. If you don't understand the system behavior and you don't know where the real problem is, you can end up manually stepping through many many layers of a system trying to see what it's doing. Add asynchonicity and this can take hours before you get to the 20 lines of logic that is the actual problem.

Ideally you have better logging and introspection, so the problem is caught in a way that leads you to those 20 lines immediately.

And of course design can make a huge difference in how understandable and localizable things are.

The problem a lot of inexperienced developers run into is if they are used to having a featureful debugger available it can become the only tool they have in their toolbox, and they are rewarded by how quickly it helps them fix the kind of mistakes their inexperience leads them to making a lot of. When they run into a real issue, they can be hitting "step" for hours....

The other pernicious side of this particular coin is that it can lead to localized understanding of the problem and make it really easy to apply a localized solution. With inexperienced people this can quickly lead to band-aid solutions all over the place. With any luck someone more experienced is looking it over and pointing out they should go after the actual problems, but left unchecked it can make a real mess.

[euiq]

I assume the parent comment is talking about "thinking" (not that I have any personal experience with that).

[beezlewax]

I've found the exact opposite of this starting out. When I started using the debugger a whole lot of things just clicked into place.

[bornfreddy]

To offer an opposite view, I haven't used (or missed) a debugger for decades, in a whole range of programming languages and environments. It was only recently when I had to disentangle some legacy spaghetti code that I have set it up - and once refactoring is done, I'll probably shell it again.

The reason I don't usually use (/need) a debugger is that I know how the code should behave, because I thought about it in advance. Or, if it is not mine, I expect it to be readable and maintainable, otherwise I push for cleanup instead. If it is written in small manageable chunks, covered with tests and if it has good logging (which is necessary anyway - there will probably be no debugger available in production), I simply don't see the added value of a debugger. If it is not, it is not a debugger that is missing. :-)

That said, it is still a valuable learning tool because it helps understand the flow of the code, and it helps when refactoring spaghetti code. Reverse engineering also comes to mind... But other than that I can't be bothered to set it up either.

[indymike]

I usually wait for someone to accidentally try to merge a bunch of conditional logic wrapping logging, prints or stdio.write type stuff and take that as the opportunity to introduce them to the debug tab in the editor... and give a quick tutorial on conditional breakpoints and how to go up and down the call stack.

It's amazing how many developers go sometimes a decade before they learn to use a debugger.