This is very similar to a POV that I've espoused for quite some time, though I phrase it somewhat differently. A symbolic debugger is good for verifying your p

This is very similar to a POV that I've espoused for quite some time, though I phrase it somewhat differently. A symbolic debugger is good for verifying your premises, but the actual troubleshooting should be done by thinking about the problem, thinking about the code, forming a hypothesis about the potential causes of failure, then confirming (using a debugger as necessary). Too many young and inexperienced developers fall into the trap of running straight to setting a breakpoint and watching what happens, which doesn't scale to more difficult problems such as concurrency and IPC. I find myself using a debugger when: 1) it's a trivially 100% reproducible problem 2) it's a completely new codebase that I'm unfamiliar with 3) it's a language that I'm unfamiliar with Otherwise the only reason I use it (or print/log statements) is, as stated, to verify the premises upon which I am basing my reasoning about the likely causes.