Debugger or print? That is the question | Hacker News Reader

Debugger or print? That is the question

1 pointzeroEscape16 comments

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.

View on HN

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.

The best thing about a debugger is that it works without any modification to the code. Prints and other debugging hacks sometimes get checked into version control and even if you are careful to avoid that the cognitive load slows you down.

That said there are certain things that confound debuggers or require technical tricks (like the method for debugging Java/C apps with both jdb and gdb which requires turning off the segfault trap). If the key to solving the problem involves understanding the sequence of events, or where the problem turns up when the breakpoint has been hit for the 74532th time prints win too.

Do you use a language with a logging facility? Learn how to use it and improve your skills.

In Java I use the debugger and unit tests a bit like I use the REPL in Python, that is I can code up an experiment in a unit test and rapidly cycle and experiment, and the great thing is I have a unit test that I can check in when I am done.

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.

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

Learn how to use a debugger. It sounds like the code base you’re working on a small enough that print statements are fine, but that won’t always be the case.

Imagine you’re working on a bug that’s extremely hard to reproduce (say, a race condition), takes a lot of time to reproduce (maybe at the bottom of a long running function), or is somewhere you can’t easily access (a remote device). Your print statement shows that $foo is -1, which doesn’t make sense. Better check what $bar is. So you now have to rerun the program, only to see $bar prints “???????” because for some reason it’s bytes but you’re printing it as UTF8. So now you have to modify and rerun your program to print out the hex values to figure out if there’s any meaning to them.

Congrats, you spent an hour getting three pieces of information.

If you just set a breakpoint, you can go for lunch and come back to a paused program where you can check the state, display information and data structures in whatever way you’d like, and proceed one step at a time to see what happens at each line of your code.

Well, most of the time we're working in Dart/Flutter. I admit that a debugger seems useful for race conditions on the back end. However, when I do systems programming in my free time in Rust or Haskell, I would try to prevent these issues which to my knowledge the languages should do by default unless you're using unsafe Rust or Haskell. So is a debugger in this case not just a bandaid?

Perhaps this is why I've never needed a debugger: prevention is the best cure.

You're only doing something wrong if you're failing to get your work done. The important part of the debugging process is the bit that happens in your head, so you should use whichever tools suit the way you think.

It depends somewhat on the type of work you are doing. Some problems are more easily spotted by dropping in and having a look at the program state, but there are problems a debugger cannot help you with at all.

I made heavy use of debuggers earlier in my career, but after a few years working in environments where logging was the only option, I found I preferred that style.

I think print debugging is great, but if all of your colleagues use a debugger, you might work in a context where that's a useful superpower.

You actually have an opportunity to learn how to use a debugger well right now and you should probably take it.

Once you learn how to use it well, you can make an informed decision on if it's actually better.

I'll use a debugger sometimes when the error is getting thrown in code I don't control but can view the source of - it can help figure out context and what the external code is doing. Otherwise I normally just put print statements for things I'm unsure of and remove them before committing.

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

I'll keep that in mind for my next interview. I find it's always best to avoid jobs that discriminate in such ways, and if not using a debugger helps me to dodge a bullet, I'll consider myself lucky.

You’re being disingenuous. Using a debugger is such an elementary part of a developer’s job that failure to master it is incompetence to me.

Well, at the end of the day, my job isn't so much to code as it is to make my employer, that is your competitor, money. So you've just called the man making your competitors a lot richer incompetent. Indeed, one of us is being disingenuous.

You are doing something wrong. There are huge productivity benefits in learning how to use a debugger effectively. Debuggers have benefits that go beyond just fixing known defects. I have disciplined myself to step through every line of code that I write while watching the control flow and state changes. This allows me to proactively find and resolve defects and inefficiencies that would have otherwise leaked through testing. Issues that you would never notice while reading source code or looking at print statement output become much more obvious in a good debugger.

I appreciate the comment, but I'd like to make some counter arguments.

You say there are benefits to using a debugger, but I've never had any issues not using a debugger. I've been coding for 26 years. The worst thing that's ever happened to me is that I once commented out a couple lines of code, forgot to uncomment them and pushed it to production. This affected maybe 0.001% of our users. Of course, I've learned to be more careful since then. Regardless, I've asked myself many times over the years every single time I make a mistake if it could have been prevented using a debugger and the answer is always no.

You say that you use a debugger to step through every line of code to examine the state and state changes, but I always do this in my head and have never had any issues. My colleagues always use a debugger and they constantly make mistakes. I often feel that the reason they make so many mistakes is because they rely so heavily on the debugger that it has a negative impact on their ability to analyze code in their head.

This is also why I always teach my son to do math in his head and never on paper. Relying too much on calculators and paper is in my opinion the reason why so many students perform poorly in math. But this is of course another topic.

It's possible you're just a much better programmer than I am and write optimal code with very few defects. I am no genius and have to rely on tools to work around my mental limitations. But I suspect you would find some latent defects in your code if you adopted the discipline I recommended above.

Reply on news.ycombinator.com