Different problems, different strategies, different tools. Does it crash? Debugger, backwards from the crash. Is there some "wtf is going on 'here'" with a pr

Different problems, different strategies, different tools. Does it crash? Debugger, backwards from the crash. Is there some "wtf is going on 'here'" with a pretty undefined 'here', and only sometimes under unidentified conditions, but likely algorithm-related? logs, assertions, printfs. Until some more clear idea of the source of the problem manifests. Does the former turn out to be truely bad, in the sense of unintended side effects e.g. by something writing beyond valid addresses and it is known what is being overwritten? Debugger. Finally, is there some misbehavior in some already identified range of code? Debugger. Of course the environment matters, too. Build time vs. debugger features available. Most effort/time is needed to solve wtf-style problems. As such, a significant part of the time/effort can plausibly spent for some form of printing. The last kind of problem (bad part of the code already known) doesn't usually need a debugger: If the faulty part is already narrowed down, it is easy to spot the problem with eyes in most cases (at least knowing the intended behavior, maybe not when looking at some random unknown code). Summary: More problems can be solved using a debugger quickly, but more time is needed to trace down those problems that cannot.