If I'm confused why something is happening I'll set a break point and then use the debugger to see what the world looks like at that point. That's an advantage

If I'm confused why something is happening I'll set a break point and then use the debugger to see what the world looks like at that point. That's an advantage when something happens very rarely. One trick is to write a test to detect a problem and then put a break point on that. Let it run until the bug gets hit. Then look at the call stack to see who was naughty. I use debug print statements to monitor running programs while doing end to end tests. I have functions to log errors and restart programs in production. Any busfault gets trapped and logged as well. Often just knowing which line of code barfed tells you what happened. Often I also log the calling address off the stack. I also have a table driven command line interface that I use heavily to poke at and inspect running programs. Having that probably reduces my need for a debugger. Unlike a debugger it's effect on a running program is minimal. For timing related stuff and debugging bus interfaces I often use a four channel scope.