As a distributed software developer, I have found debuggers less useful these days. If I need a debugger, it probably means I don't really know the code that I am working on.

Good IDEs with good static analysis, good unit test/integration test/e2e test coverage, a true understanding of the code base before changing it, all these avoid most bugs.

When the production hits a bug, good monitoring and logging can help root-causing. It is extremely difficult to debug and reproduce a bug in a distributed environment. Many bugs I have root-caused are purely based on monitoring and logging then show the proof with mind-execution of the code.

If you're working in a large legacy system where it's not feasible to fully know the code you're working on, I find that debuggers both help me find bugs quicker and improve my understanding of the code.

Not a big name myself, but I'm always surprised that this surprises people. I mostly use print statements, simply because a) every environment has them, b) there is much less (none) fiddling involved to set them up, and c) because debugging is rarely needed anyway, assuming you are working on your own / your team's code (and that you are half good). I think the last time I have used a debugger was on what I think would be a definition of spaghetti code - not proud of it, but I did learn not to do that. :)

This is interesting, I use the debugger a lot, in whatever language. I've debugged with CLI interfaces and I've used IDEs.

I don't want to claim this is superior to printf debugging, or whatever other technique. I just like seeing the code executing, and debugging some weird error can sometimes be an almost relaxing activity, as you just step through the code one by one and try to keep track of what's happening without needing to think more than 2 or 3 steps ahead.

That said, I'm also the guy who will happily put breakpoints into internal framework code (e.g. Spring Boot) so that I can understand why the framework doesn't do what it's supposed to do. Usually, I find the answer, although maybe in some cases it would have been more economical to use a workaround instead, but that would leave me dissatisfied...

I rarely use the debugger in highly async systems (e.g. node) because it's just a mess, but in C/C++/Go/Java where there actually are good debuggers and you tend to have chunks (e.g. entire functions) of synchronous code, I find it very, very helpful to step line-by-line through most nontrivial code at least once for any major code path. A long time ago, I had a sort-of mentor who, whenever he looked at new code, asked the author "have you single-stepped through it yet?" so I did it to humor him, but the number of times I caught errors was eye-opening, so to this day I still like to do it.

It's not only a matter of usage. Many good programmers will argue that "actual debugging tools" are mostly useless and that logging the execution of your program is a more productive use of your time. In some sense, time spent inside the debugger is lost forever. On the other hand, the time spend writing good logging code is really worth, and will be especially helpful to detect future bugs that you have not yet written.

I'm not a good programmer, but I can say very proudly that I've never used any debugger (except for assembly language, where the debugger is more like an interactive shell).

I’ve found that the more state and code paths to the bug, or the more confused I am about the bug the more likely I am to need a bunch of print statements. Debugging for me is a fine scalpel that works great when I think I precisely understand what is going on but my code appears to be doing something impossible. Starting stepping at the top of a program and just looking for what goes wrong is a usually a huge time sink.

Debuggers are in almost all cases a superset of print statements. However, you have to learn how to use them effectively since there’s so much you can do. I assure you that single stepping to the problem is not how to use a debugger to find problems ;)

No one has ever really used the debugger at any of the c++ shops I've worked at almost exclusively logging. No one even knew how to get the build system to produce debug symbols at my last job.

that's a feature not a bug. you see... in today's world if you need to attach the debugger to understand something you have already lost. why? because you should not be able to attach a debugger to a production system (if you can that is another can of worm). ideally the logging + metrics of what you are building is enough for you to understand what is going on.

there is one notable exception to the no debugger rule: if you are learning/exploring a new code base on your dev machine and/or when writing tests [to cover legacy code]. but apart from that, unless your work is really special, you should not need a debugger.

Even George Hotz does it. Although he did write a debugger.

The one exception I remember is Knuth. He loves a debugger.

IME it depends on what kind of bug you are dealing with, and also what language and debugging tools you have available. Historically I used to do a lot of printf debugging. The other day I was helping a friend write some C++ code and I had a bug where only the first element in an array was matching a condition. Using the debugger in my IDE I set some breakpoints in a couple of places that seemed close to where the problem was. The advantage of the debugger is that it is fast and easy to see at each breakpoint what all of the defined variables and their values are. If you do it manually you could easily forget to print one of the variables that you ought to be paying attention to. In this case the debugger helped me figure out the problem within only a couple of minutes which was great because we were really pressured for time at the moment.

Furthermore, in response to what one the siblings said about creating logging infrastructure, in my own debugging I tend to not find much value in keeping a bunch of logging around. For me keeping logging around boggs me down. Typically what I will do if I do printf debugging is I add logging statements, hunt down the bug and then commit the fix and the added printfs because they add context but then I immediately make another commit where I remove the printfs. This way I have them in the version history should I need them, while at the same time avoiding extraneous log entries at later time.

And really I’ve found that over time I do printf debugging less and less.

I attribute this to mainly four things:

1. A friend of mine that encouraged me to use an actual debugger

2. Watching Jonathan Blow program on his Twitch stream and observing how proficiently and fast he is able to get the information that he needs by using the debugger

3. CLion. As much as I like the commandline, I never found gdb with the commandline interface to be a suitable tool for me. Whereas with CLion I get a good debugger that makes visible to me most of the information that I need while I am debugging

4. Through years of programming I have learned to recognize many of the types of bugs that I produce. Also, with experience I have learned to write code that is easier to reason about and to debug as opposed to in the beginning where I was trying to be “too clever” for my own good with the code that I wrote.

I think another of the sibling comments put it well about the debugger being like a scalpel. Trying to step through a whole program and following what’s going on would be slow, confusing and ultimately error prone. In order to effectively use a debugger I think you need to have a hypothesis about what is causing the bug and then set very specific breakpoints that you make use of in order to figure out where things are going wrong. From your initial observations you can set more breakpoints at a more coarse level (shallower call stack levels) and use those to observe what leads up to things going wrong.