Debugger or print? That is the question

At work, all of my colleagues use a debugger. I'm the only one who doesn't. Whenever I try using a debugger, I fail to see how it is helpful. When there is a bug, I simply look at the error message, anticipate where the problem is, analyze the code and either fix the problem immediately, or if I'm unsure of something, I just write a print statement with the information I need to know, hit F11 to refresh the console and get immediate feedback.

I wonder, am I doing something wrong? Is there something I'm missing? Ironically, my colleagues are always the ones to come to me when they can't debug something.

I've used printf (or equivalent) more often than I've used a debugger but sometimes a debugger is the right way to find a problem. For example, you mention an "error message", but I've occasionally had situations in which a process running a binary built from a large code base that I have never even looked at (though I do have the source) dies for no obvious reason and with no useful output, but I've been able to restart everything, attach a debugger, and then, when it dies again, with great luck get enough information from the debugger to fix the bug faster than it would take to rebuild everything let alone insert printfs everywhere where they might help. Usually that's been in cases where I know roughly the sort of thing I'm looking for because I know the main differences between the system it's failing on and the systems it used to work on, though I have absolutely no idea where that sort of thing might be in the code that I've never looked at. If I'm running code I've just written myself I usually find I have no use for a debugger.

I'm assuming you mean a software-only debugger, and I mostly feel the same way as you. The process of starting the debugger, setting breakpoints, etc. feels a lot like going to the doctor when you're sick rather than self-diagnosing, which works great 90% of the time and doesn't involve getting into the car and lots of waiting.

I could see a strong use for things like multithreading, profiling, seeing a list of variables/values that are in-scope at a breakpoint. The more complex the software, the more useful...

The last time I needed a software debugger, a tool I was using would communicate with another by sending its PID as an ID. Problem? The tool thought the PID fit in a 16-bit, so it was sending a totally bogus number. I probably would have found this eventually, but with the debugger, it was as easy as "Why is the sent PID 39283 instead of 170355?" This only occurs after Windows has been on for several weeks and enough conhost/svchost/wslhost processes push new PIDs above 65535.

Humorously, such a bug goes away when you "turn the PC off and on again"

-----

Hardware debuggers (for microcontrollers) often have a whole host of benefits that are immediately obvious once you involve any physical I/O. Also, they're vital for things like event logging (for Arm, PMU events flag for cache misses, branch events, operation stalls, and much more) or seeing what's happening with an off-chip device, peripheral, other cores, anything to do with watchdogs, etc.

Writing something like impact failure handlers for a drive head controller for a hard drive, you'll want to be able to set an external trigger as soon as the failure is initiated, connect that to your debugger via one of its trigger-detecting inputs, and then you can capture the real-time data and execution traces and move back to the exact moment the failure occurred, how your variables changed, and what exactly the failure handler did to ensure the drive head attempted to park as soon as possible. In short, this is not printf-able, but it is also an extreme example.

I've interviewed folk who say they don't use debuggers. They usually don't get the job.

Yeah, I was referring to software debuggers. But I can definitely understand how a hardware debugger would be useful.