IMO, debuggers, logging, metrics, tracing and the other tools focus on different things and are good at different things. Debuggers are extremely powerful in t

IMO, debuggers, logging, metrics, tracing and the other tools focus on different things and are good at different things. Debuggers are extremely powerful in the correct situation. If you can reproduce an issue in a controlled fashion, debuggers are nuts. In many cases, you drop a breakpoint where the exception/panic/segfault occurs, trigger your reproduction, and the current context + variable view just throws the problem in your face. If that fails, you breakpoint earlier and that's usually it. I've very much changed my opinion there: If you have a reproducible problem, and the source code, use a debugger. It's better. On the other hand, good logging and tracing are better in other cases. If we call a debugger spear fishing - targeting a concrete target specifically - good logging and tracing are more of a drag net. Like, in my last job, we had a bug that effectively nulled user accounts, which possibly voided thousands of euros of investment. Except, it occured about once or twice a week, across billions and trillions of interactions with the service. This turned out to be a very, very specific synchronization issue in a rarely used and rarely contested component, but very active players were more likely to be affected by it. Very messy. We couldn't have caught that error without just dumping all errors and a lot more events into a central bucket and then analyzing from there. But, in a similar way, this kind of event collection in turn allows analysis like: How critical is this thing? An error occuring 20 times a day on a production system for the last 30 days probably isn't that important, else we'd have had a ticket 20 days ago. Not something a debugger can tell.