When people say “debuggers are useless and using logging and unit-tests is much better,” I suspect many of them think that debuggers can only put breakpoints on certain lines, step-step-step through the code, and check variable values. While any reasonable debugger can indeed do all of that, it’s only the tip of the iceberg. Think about it; we could already step through the code 40 years ago, surely some things have changed? Tl;dr – in this episode of old-man-yells-at-cloud, you will learn that a good debugger supports different kinds of breakpoints, offers rich data visualization capabilities, has a REPL for executing expressions, can show the dependencies between threads and control their execution, can pick up changes in the source code and apply them without restarting the program, can step through the code backward and rewind the program state to any point in history, and can even record the entire program execution and visualize control flow and data flow history. I should mention that the perfect debugger doesn’t exist. Different tools support different features and have different limitations. As usual, there’s no one-size-fits-all solution, but it’s important to understand what’s theoretically possible and what we should strive for. In this article, I will describe different debugging features and techniques and discuss the existing tools/products that offer them. Disclaimer. In this article I mention various free and commercial products as examples. I’m not being paid or incentivised in any other way by the companies behind those products (although I will not say no to free swag should they decide to send me some cough-cough). My goal is to raise awareness and challenge the popular belief that “debuggers are useless, let’s just printf”.