I do not use a debugger (2016)
&gt; Doing “something else” means (1) rethinking your code so that it is easier to maintain or less buggy (2) adding smarter tests so that, in the future, bugs are readily identified effortlessly. Investing your time in this manner makes your code better in a lasting manner… whereas debugging your code line-by-line fixes one tiny problem without improving your process or your future diagnostics.<p>I&#x27;ve been a professional now for about 15 years and very, very rarely do I get to work on &quot;my code&quot;. Almost all of the code I have to work with was written by someone else originally and I have to just modify the system for new requirements. Tests do not exist or if they do they are largely incomplete.<p>So the only thing to do is to step through find the problem, fix the ticket and move on.<p>Sure If I get to design the system I normally write it very simply &#x2F; well structured with appropirate levels of abstraction and with enough tests to expose the bugs in my code. But very rarely do I get paid to work on my code, because my code doesn&#x27;t need a lot of maintenance. I normally am asked to make changes to bad systems.<p>&gt; Brian W. Kernighan and Rob Pike wrote that stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places. Kernighan once wrote that the most effective debugging tool is still careful thought, coupled with judiciously placed print statements.<p>Thinking harder when I have a project with millions of lines of code (this is normal in large financial systems) won&#x27;t help me. A debugger will.<p>I think a lot of these famous programmers have never had to work with something terrible and probably never will and that is why they make such blasé statements.