These takes on debugger use always mystify me. They always seem to indicate that they think debuggers are used by single-stepping thousands of times as if they

These takes on debugger use always mystify me. They always seem to indicate that they think debuggers are used by single-stepping thousands of times as if they are using them to watch their program execute at 1,000,000,000x slowdown. Even primitive debuggers like gdb are not intended to be used like that. You theorize a failure mode, identify the proximal causes, then set breakpoints at the earliest suspicious points. You then examine the actual state to determine if your mental model of the code matches. You can then single-step to verify that the suspicious piece of code does or does not do the correct thing. If you are feeling really adventurous and are willing to try technology that is only 20 years old you can use time travel debugging. Then you do not even need to think about how you debug. You just hit the bug then run backwards to the cause of the error. Then you examine the entire state of the universe at the time trivializing basically every bug. You can use even newer stuff like high grade visualization of the entire program execution which trivializes bug detection, performance enhancement, and system understanding. These articles always seem stuck 50 years in the past and even then seem to always be arguing that hammers suck because they keep trying to hit the nail with the handle.