Why are we not using debuggers more?

For me debuggers are the first resort. I learned a long time ago that if you get in the habit of hacking the code to debug it (say adding print statements) you will eventually check in debug-related changes that you shouldn't. Using the debugger means you don't have to hack the source code.

I use Jetbrains tools and have an easy time debugging in Java, Python and Javascript. In Java I'd say that you can use unit tests to interactively experiment the same way people do with the CLI in Python with the difference that you get unit tests out of the deal as opposed to having lines scroll away in the console.

I use WebStorm to debug Javascript programs that run in npm but if it is running in the browser I just use the "developer tools" from Firefox, Chrome, Edge or Safari. I think there is some way to attach WebStorm to a running web browser but I've never figured it completely out.

I think the Unix culture is allergic to debugging. It's not that hard to use gdb from the command line and in fact you can do some pretty awesome things with it such as embedded system debugging or debugging the C++ and Java sides of an application at the same time, but for a long time I kept trying graphical front ends for gdb such as ddd that "just don't work".

I use a debugger every day. Delve[0] Go's debugger made me love the process of debugging my code – either attaching the debugger to an existing running process or the feedback loop of debugging the test code until make it passes the test case.

Back in the days when I didn't use one, it was a miserable developer experience. Thanks to Go and his great decision of having unit testing built into their standard now writing tests and debugging them is a joy.

Far are the days of not using a debugger because the programing language of choice didn't treat debuggers/unit testing as a first-class citizen. I could say that now I sleep a lot better thanks to coding my backends on Go and having the confidence that I can go as much depth as I want to fix any bug.

Debugging for me is an automatic action like drinking water when you're thirsty; two clicks (set breakpoint and click the debug button) and I'm back into the debugger, again.

[0]: https://github.com/go-delve/delve

I use debuggers, but only if "prints" don't help me figure out the issue at hand first. Debugging via "prints" works out of the box.

You put a "print" statement dumping whatever data structure you want, you run the program again, and voila you got something. Now, the "where to put the print" is an art on itself of course. If you don't know where to put it, then either you start writing multiple "print"s here and there (following an approach similar to binary search) or you use a debugger and go step by step until you find right place to inspect.

The problem with debuggers is that they do not work out of the box. If you use the terminal, then you have use an external program and read its manual to understand how to debug, how to put breaks. Depending on the platform you are using, you may require even an executable to run the debugger on. Sometimes you don't have an executable. Sometimes you don't know where the "entry" point of your program is, but you know where the bug relies. Some debuggers require you to point the debugger to the entry point.

If you use an IDE like Jetbrains', then for debugging you need as well to do some (minimal) setup as well (the last week I had to debug a Node.js program: it was simple, but it didn't work out of the box. Also, when I open my IDE on a different Node.js repository, my debugging setup was gone).

Some ideas:

First, if you can fix most issues with a glance or a brief stare, using a debugger never really feels necessary. It may also feel less like using your own brain and solving a puzzle, and puzzle-solving is a huge part of human psychology (see post title).

Also, the story of the last N years has been the text editor, not the IDE. The IDE and its world is really where the integrated debugging story is a big deal.

But if you are using a text editor--or text editors--integrating debugging is less of a thing. Your time may be better spent with various productivity-focused changes for ergonomics, like studying or changing keyboard shortcuts, installing or writing plugins, setting up your own scaffolding using system tools integration, and so on.

Plus once you know the various shortcuts, it's maybe more fun to use them and zip around adding prints than it is to debug. You also gain practice this way, after all.

But if you moved from text editors to IDEs, IMO you probably brought that same set of practices along.

Anyway, good q, I've thought about this recently as well.

I use debuggers all the time. Don’t repeat yourself and keep it simple stupid goes a long way. I’d much have something readable and easy to follow than something clever.

I program in Scala and didn't know what IntelliJ debugger could do until someone taught me how to use it (including the nifty trick of setting break points inside 3rd party libs).

Sometimes you don't know what you don't know.

But yeah, these days I rely on the debugger heavily. Even for Python :)

I make an effort to use a debugger first.

Right now I'm writing some stuff which takes over the terminal and works in recursive loops (ncurses roguelike map generator) so print debugging is a hassle. It's actually quicker to use a debugger.

I find that attaching gdb and running "bt" and "info locals" or inspecting variables with "p" is much cleaner than printing, and helps me visualise what the code is doing much better.

This use of a debugger for "little things" is immensely helpful for when I need to use a debugger at work to solve "big things", which are usually remotely and after-the-fact with a core file, so printing isn't even an option there.

I'm getting more into using debuggers lately. They can really help they just take time to learn.

As to why they are a last resort. For me it was just having to learn the debugger and also setting up the debugging environment. For every binary needs to be built with debugging symbols and any libraries you're wanting to step through you have to find the symbols for those too.

Also I think it depends on how low level the language and what kind of program it is.

Some languages/environment don't have debuggers or they aren't very good. I wouldn't say most debuggers that are mature are super great to use either.

When build times are short, spinning up a debugger is overkill compared to adding a couple of debug statements.

The code I write is also a lot more asynchronous nowadays, and debuggers are fairly worthless for async code imo. Pausing on a breakpoint conceals issues with asynchronous timing that good logging will show immediately.

I still believe debuggers should be a part of every developers toolkit, but like anything else, pick the tool for the job and sometimes print statements are just the easiest and fastest. Actually in a lot of cases.

Not me. I love debuggers. One of my favorite features of Java has long been the JDWP support for remote debugging. Being able to fire up Eclipse (or whatever) and attach to a running process on another machine and step through the code... amazing. Not sure if other platforms have caught up in that regard or not, but to me for the longest time that single feature was one thing that made Java very cool in my book, compared to a lot of other environments.

One doesn’t often reach for a tool that isn’t convenient to reach for, even though that tool may be the best available for the task at hand.

If you force yourself to use the debugger more, you will in the process both familiarise yourself with it and iron out any configuration kinks. Learn those keyboard shortcuts, figure out how to make it autoconnect and break on exceptions, find out how to evaluate expressions on the fly, …

You + That tool = maybe goodness. Maybe not.

I like debuggers, but I don't always use debuggers. Typically because I can find the problem quicker w/ a puts/print/etc. than the time it takes me to run the debugger.

I also do a lot of web stuff, and if you're running some server process and you're not running the server process through a debugger directly, then you need to find and attach to the server PID, etc., then maybe deal with threads, and it's just a lot of upfront effort when I could just find the issue by throwing a puts/print somewhere or writing a test.

I'm not anti-debugger, I'm just busy and it's easier to put something in my code (which is how I frequently jump into debuggers too, e.g. binding.irb, binding.pry, debugger, byebug, etc.)

the CLI debuggers (gdb, lldb, etc.) are great when I really need them, but they're a pain in the ass to setup with things that are not C or C++, editor integrations sometimes need setup, and using them without setting breakpoints visually is tedious.

The people I've met who don't use debuggers either write very uninteresting code day to day or just get by enough with their old ways of print statements, enough to not feel compelled to learn to set a debugger up. But I think that's dumb, and it's almost always worth understanding how to set up, especially in a large codebase.

I am sadly not using a debugger because the last two or three times I've tried to set up XDebug for PHP, it just hasn't worked. I have 15 years experience with the language. Have tried multiple IDEs, multiple plugins, multiple browser extensions. Have tried multiple ways of running PHP (docker vs. native). I think the last time I might've had XDebug running properly such that I could do debugging in an IDE was probably 2018 or so. It wasn't too long ago that I found the `dd()` command, which is really quite handy and has gotten me by since then.

I'll give it another crack because I have just started a new job (new machine, new PHP, new everything) but I have my doubts it will work this time, either.

Setting up debugging for PHP has got to get a whole lot easier and user-friendly, IMO.

My team regularly uses debuggers developing our C/C++ codebase. Often they are just one part of the workflow, combined with logging and visualization tools (to look at complex data structures as graphs). Debuggers often help track down where something bad happened to narrow down the search through logs and traces, and to figure out what part of a giant data structure to focus on. Most people I interact with work similarly : a combination of debugger, printing, logging/tracing, and viz. We tend to use debuggers less in other languages for various reasons (either poor debugging tools, or failure modes that are easier to understand via other methods).

My preferred debug method is to have a program that I run to verify that it misbehaves. Then I remove some part of the source code, rerun it and verify that it still misbehaves. If it doesn't misbehave, I reinstate the removed code and I remove a part of the reinstated code that I suspect is misbehaving and then I rerun the program. This continues until I have found the offending line, at which point fixing the bug usually becomes trivial. Debuggers are nigh useless in this workflow.

I do use a lot of analysis tools like Valgrind which imho are way more useful than debuggers. Linters and static analysis tools can also be really useful for early bug detection.

I love using the debugger but now I want one where I can rewind the program a few steps if I want to. The use case I have is to go back and forth trying out different combinations of variables on a section of code. Even if I could manually set a flag to store the program state at certain portions so I can return there, that would work great.

Other than that, debuggers are very superior to print statements and such. You can’t pause a print statement and inspect the objects you didn’t print!

I am a Data Scientist turned manager so I don't consider myself a super senior dev focusing on other areas. Having said that debugger is amazing, especially for data intensive applications where it's the data that breaks the flow usually. I know there are cases where defaulting to prints is easier, but I use debugging whenever I can (if I still get to write/debug code)

In my case, it's a technical limitation: the code that I write runs on a remote computer, not my laptop.

I know that "remote debugging" is a thing, but I would need to talk with our network guys about firewall exceptions to allow me to connect to the Kubernetes pod over port XYZ. That sounds like a hassle, and I'm not sure they'd allow it.

I got in the habit of using logs when it was faster than reproing bugs or more reliable (couldn't repro the bug). There's niche cases where the debugger is better, but logging has generally helped me more.

I try not to debug code with print statements but the build time w/ vs. w/o the debugger is so much longer that it makes sense for small issues to debug with print statements on occasion.

Using a debugger for async codes introduces timing bugs.

I avoid debuggers because if I can't debug something without them, said something is too complicated for me to understand now, let alone in the future. Moreover, if said something is that complicated, it is almost certainly wrong in several subtle ways.

One nice property of asserts is that they keep working even when your attention is elsewhere.

Because developers are deathly allergic to understanding/reading other people's code, and/or do not write them for

t. Grumpy maintainer

John Carmack's view [0] on debuggers (from Lex Fridman Podcast podcast video)

TLDR: He doesn't understand why a lot of SV big-tech companies are hostile to debuggers.

[0] https://youtu.be/I845O57ZSy4?t=3410

developers are lazy

Debuggers don't give you enough information when you want more, and too much information when you want less.

Learning and effectively using a debugger can require as much cognitive load as programming itself.

Given that, using a debugger takes you out of your programming mindset and into debugger mindset. Using prints, asserts, etc. keeps you in programming mindset, so you can find and fix the problem and get back to coding without the need for cognitive gearshifting.