If you are spending endless hours puzzling things out, you already have no idea what's going on. So sure, go for the debugger if that helps. But that's not what's he's talking about.
Like him, I use a debugger rarely. Not because I'm opposed; they're great when they work. But it means I don't understand what my software is up to. Which for me is a sign of design and code quality issues. Or just ignorance. Both of which are solved by working to clean things up.
Cleaning up is fine and commendable if you're working on a piece of software from scratch.
My code is often just a class or two plugged into a behemoth. I know exactly what my code is doing, but not exactly how it's being called by the platform, or what responses is it getting.
I don't think that using a debugger = you don't understand whats going on in your code. I've had many situations where it helped me understand a great deal what was going on. Plus, its a built in tool, so I don't have to waste time writing logging code or anything of the sort. I've also had situations where I worked with another programmer, who rarely used it, and often times got his understanding wrong when he puzzled it out. He eventually figured it out, but it was debatable whether it saved time from using a debugger.
A situation where a debugger helped you understand a great deal has to be a situation where you don't understand what's going on.
I agree a debugger can help you figure out mysteries. But when I find myself using one, I try to ask: how could I have avoided having a mystery in the first place. Common answers: better tests, cleaner code, better design.
>> Common answers: better tests, cleaner code, better design.
I wouldn't be so keen to say that these help "avoid mysteries" in the first place. Many algorithms that have better time complexity and space complexity are often much harder to understand than writing algorithms that sacrifice those qualities, but can be understood at first glance. For example, is it easier to understand code that performs a lot of bit wise operations, which is probably better designed and more cleaner than a piece of code that performs operations with strings and object?
The more experience I gain, the more I tend to prefer configurable logging over interactive debugging, for much the same reasons that I like automated tests and shell scripts. For a simple, one-off job it’s fine to do things manually, but a small investment in a systematic, repeatable approach quickly pays off.
Like him, I use a debugger rarely. Not because I'm opposed; they're great when they work. But it means I don't understand what my software is up to. Which for me is a sign of design and code quality issues. Or just ignorance. Both of which are solved by working to clean things up.