I'm definitely a fan of type checkers and formal verification. The problem is that even those tools permit not just specific bugs, but whole classes of bugs thr

I'm definitely a fan of type checkers and formal verification. The problem is that even those tools permit not just specific bugs, but whole classes of bugs through verification; there are inherent limits on what any tool can give you. It's a similar thing with test cases, too. So, I'd say that when you use a debugger in tandem with a bunch of other good tools then the bad habits that the debugger encourages just matter less. There are fewer classes of bugs that will make it through verification and those other tools force you to understand the code at least well enough that you can pass their checks. However, you still need to read to generalize and fix those remaining bugs properly, and the debugger will push you toward a fast single point resolution rather than a slow but general resolution which is what you'd get from careful reading and thinking. The big argument against this is I think is if you're working with something where a large number of bugs is acceptable. Like, if you're hacking together a demo/prototype and you just need X to work then a debugger might be the way to go: Just ignore the other bugs because who cares? Or if you're working with some legacy software that's generally known to be buggy and you just need to fix some specific critical use case quickly. It's also just hard. Like you said, being able to read complex code and then systematically coax the bugs out of it with your brain and eyes definitely takes a lot of practice and the more that that can be supplemented by automation and good habits, the better.