As the saying goes, you can spare yourself 10 minutes of thinking with a few hours of debugging. A debugger works if you're in unknown territory, e.g. an inher

As the saying goes, you can spare yourself 10 minutes of thinking with a few hours of debugging. A debugger works if you're in unknown territory, e.g. an inherited code base or some third party library. You have only a vague idea what the code does, you don't know if the original author was good or bad, you can't modify the code... Also good if you have some platform corruption going on, like a C pointer gone wild and overwriting unrelated data, hardware that's not completely functioning as it should, some virus scanner or security contraption injecting its own crap in your code for your supposed good... Using a debugger on your own code generally means you did not think things trough. Adding assertions will help you trap the trouble closer to its point of origin. Print debugging is good for dumping inputs and outputs, and maybe complex intermediate state. As you have a full programming language available, you can add a few if statements to only dump state if it is relevant to your problem. The nice thing is, assertions and print debugging nicely evolve to production: The first can be enabled with a feature toggle, the second nicely evolves to logging. This means your prod executable is not only good at doing its job, it's also good at helping you troubleshoot on a bad day. Use the dev bugs to train yourself and your program to troubleshoot the prod bugs.