[horsawlarway]

I feel like your understanding of a debugger is very limited.

To me - A debugger is the instrumentation you're talking about, but created by the language/runtime developers instead of having to be remade by you, poorly, for each new project.

A good watch statement is a hell of a lot more useful than an assert - even though they both try to do the same thing.

Not even touching the places where a debugger solves a problem you simply can't touch with instrumentation after the fact (crash dumps immediately come to mind...).

And neither of them are (in any sense) a replacement for writing a test after you solve the problem, or adding comments so the next developer has context on the why of that piece of code.

[enriquto]

First of all, I agree 100% that a debugger is an indispensable tool. I just say that it is often not necessary or useful when you are writing new code or reading old code that you are supposed to edit. Your example about interpreting a crash dump is definitive.

I've had a fair share of using debuggers in my life, and I ended with my anti-debugging stance as a matter of fatigue, and a sense of time lost. I know what debuggers are capable of, especially regarding data visualization. But for your example of the variable watch, what are you going to watch, precisely? That the value of a variable is always positive? That it increases one by one? All these things are better served by assertions. What kind of information can be inferred by just looking at the evolution of values of a variable that is not easily formalized as an assert or a simple in-code test?

[antoineMoPa]

It's weird to write the test after solving the problem. You should write the test before solving the problem to get the most benefit. You can then edit + compile + run test until the test pass and normally this is shorter than the "edit+compile+start app+replicate bug manually in application+debug" loop.

[horsawlarway]

Depends on the bug - most times I'm breaking out the debugger it's because I have a timing/race condition somewhere, or an unexpected interaction with some other service/component.

Basically - the debugger is not a tool I use if the issue is clear and reproducible.

Those are also issues where it can be hard to write a correct test up front. Typically - tests are passing already, but we're seeing intermittant problems somewhere. Once we understand the interaction and the root of the problem, it's much easier to put a test in place.