>>we find stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places.<p>This ignores the typical scenario where you are working in a business application that you've never seen most of the code, only the relevant parts of whatever tasks you have done in that program, and all of the sudden you are asked to solve a bug or make a change in some place that you didn't know even existed, the original developer is long gone, is not documented, and chances are that there are many great coding horrors. A debugger can be really helpful to uncover how that code works.<p>Also it assumes that the only possible use of a debugger is set a breakpoint and then follow every next step until the end, but this is actually not the case. A debugger allows you set conditional breakpoints, skip whole sections of code, evaluate code using the actual context that the application had when it was stopped, make changes to variables while the program is being executed, it is a great tool to explore code and behavior.<p>I respect that some people may not like them and don't want to use them, but I find pretty dumb the idea that not using them is superior and you are a worse programmer if you do.
In my experience, developers who don’t use a debugger belong to one of two groups:<p>1.) Older hacker types for whom it was previously unavailable or difficult to set up, so they learned to work (well) without it.<p>2.) Juniors/fresh grads, who often seem intimidated by it, likely because teachers and online resources didn’t emphasize it sufficiently.<p>I think the first group would benefit from introducing a debugger into their work process, but for the second group it should be essential.
Classic interview question. Tell me about the time you used a debugger to solve a programming issue. Saying "I don't use a debugger" is like saying to a C programmer "I don't use pointers".<p>Cut the interview short. Thank them for their time then escort to the exit.
I am surprised to find in these comments that using the debugger routinely and by default isn't a popular idea. I couldn't do my job as well as I do without having the reflex to use the debugger. I shouldn't be surprised though, the last time I watched a coworker roll his face on the keyboard trying to debug something the conversation went something like:<p><pre><code> - Me: Just use the debugger...
- Him: But it's hard and annoying to use the debugger
- Me: It's hard and annoying not having the skills or reflex to use the debugger by default
- Him: ... ok I agree ... continues rolling face on the keyboard and add print statements everywhere
</code></pre>
I think much of the sentiment in these comments is sounding like "that's not how I work so I will defend myself". Just learn how to use your debugger and integrate it into your work flow. You don't need a special IDE to use a debugger in most languages if that's the perceived problem.
I feel like many of the commenters here haven't experienced enough corporate environments. I love using a debugger for open-source projects I work on and web apps I used to do for clients, but when you're working for a big company it's usually difficult to impossible to attach a debugger. Almost all of them have such convoluted setups that you'd need to use remote debugging, which is difficult to configure. You can barely use your own IDE in some of the FAANGs. This was the catalyst that made me develop PySnooper.
How quickly do you guys whip out the debugger when you encounter a bug?<p>I often can figure it out by reading the code (I'm the quickest jump-to-source in the wild west!) quicker than I can from inserting print stmts or hooking up a debugger.<p>I've also decided that I dislike having my IDE be my debugger, I prefer having an entirely separate UI for that. Maybe this is because I use Emacs and DAP mode and gdb is quite poor there, I'd rather use something like gdbgui.
There are cases where I use print debugging in Firefox because it's ironically often faster to rebuild and rerun than for gdb to load the debug info. Also for rust, it can be much more convenient to use the dbg! macro for pretty printing rather than dig in the mess of values in the debugger.
On one of Gordon Ramsey's shows he had a chef who purported to be one of the best in the world. While cooking his scallops kept sticking to the pan, this makes them look bad and Gordon won't serve them looking like that. Gordon yelled something like "Why aren't you using the non-stick pans, it's right there in the name, non-stick". I hear his voice in my head at least once a month when one of the people I work with spends a week on a bug and never once whips out a debugger. It's right there in the name guys.
When I write code that has multiple, interrelated parts, before I ever run it I step through it in the debugger to verify that my logic is correct, I didn't make any off-by-one errors, library calls return what I expect, etc.<p>I especially do this when the code has destructive side-effects (a file gets moved/deleted, a database get updated, whatever), so I can skip over any external actions I don't actually want to occur until I'm ready for a full test run.<p>Everybody does this, right? Right???
I look forward to seeing the author write about Pernos.co, an <i>extremely underrated</i> debugging tool that basically changed my and my team's lives when fixing bad code.