Hacker News Reader

Comment by defdac | Hacker News Reader

"You have to ask yourself: "Do I understand why my program is doing X?"" "I almost never use a debugger." "And if your program is so complex that you need a debugger [simplify]"

To me, being afraid of a debugger is like being afraid of actually knowing exactly what is going on - being lazy and just read logs and guessing what might have gone wrong, instead of letting the debugger scream in your face all the idiotic mistakes you have made.

I would argue that using the debugger is being lazy in an intelligent way, instead of spending hours reading endless logs trying to puzzle together logic the debugger can show you directly.

View on HN

Agreed.

Logs are good. They're effective. They're easy to use. You can filter, search, and aggregate them. Without printf()s and log statements, my world would be chaos and darkness.

But a debugger gives you superpowers:

  break blah.c:180
  run
  thread apply all bt

You can stop time. You can get backtraces. You can see and modify every aspect of the process. Many debuggers even let you attach to a running process and do these things.

Changing log statements means stopping and re-running your program. If startup time is large, this can hurt productivity.

It's rare, but logs can mislead. With async stuff, logs don't always get printed out in the right order (hello, Node.js and Twisted). A debugger is crucial for figuring out that sort of unintuitive behavior.

There are Node.js debuggers? Oh, seems so: http://github.com/dannycoates/node-inspector

Node has a built-in debugger. Just run `node debug blah.js`. There are some issues with it though. The commands are different from any other debugger, and it has problems handling signals: https://github.com/joyent/node/issues/3167

This is an old argument, and the problem tends to be that each side reads the extreme position even when it was neither written nor intended.

I seldom use debuggers, but sometimes it's the right tool. Others I know and respect use debuggers much more. Even among people who are great at what they do, people work differently.

For those of us who prefer to use debuggers sparingly, the worst abuses stand out: coders wasting hours playing with breakpoint and stepping through code, eventually finding the point where it breaks, and then still not understanding the actual problem or how it should be fixed. This kind of situation is certainly not the case for good developers, but it's depressingly common. Good developers who use debuggers also see these abuses, but they respond with "you're doing it wrong" rather than "put away the debugger." IOW, anyone/everyone tends to correct someone by showing them how they do it.

If you are spending endless hours puzzling things out, you already have no idea what's going on. So sure, go for the debugger if that helps. But that's not what's he's talking about.

Like him, I use a debugger rarely. Not because I'm opposed; they're great when they work. But it means I don't understand what my software is up to. Which for me is a sign of design and code quality issues. Or just ignorance. Both of which are solved by working to clean things up.

Cleaning up is fine and commendable if you're working on a piece of software from scratch.

My code is often just a class or two plugged into a behemoth. I know exactly what my code is doing, but not exactly how it's being called by the platform, or what responses is it getting.

Sure. In my view, that's another context where I don't know what's going on. Ergo, sometimes I give in and use a debugger.

I don't think that using a debugger = you don't understand whats going on in your code. I've had many situations where it helped me understand a great deal what was going on. Plus, its a built in tool, so I don't have to waste time writing logging code or anything of the sort. I've also had situations where I worked with another programmer, who rarely used it, and often times got his understanding wrong when he puzzled it out. He eventually figured it out, but it was debatable whether it saved time from using a debugger.

A situation where a debugger helped you understand a great deal has to be a situation where you don't understand what's going on.

I agree a debugger can help you figure out mysteries. But when I find myself using one, I try to ask: how could I have avoided having a mystery in the first place. Common answers: better tests, cleaner code, better design.

>> Common answers: better tests, cleaner code, better design.

I wouldn't be so keen to say that these help "avoid mysteries" in the first place. Many algorithms that have better time complexity and space complexity are often much harder to understand than writing algorithms that sacrifice those qualities, but can be understood at first glance. For example, is it easier to understand code that performs a lot of bit wise operations, which is probably better designed and more cleaner than a piece of code that performs operations with strings and object?

The more experience I gain, the more I tend to prefer configurable logging over interactive debugging, for much the same reasons that I like automated tests and shell scripts. For a simple, one-off job it’s fine to do things manually, but a small investment in a systematic, repeatable approach quickly pays off.

Using logs wins against debuggers a few cases though:

- Your program runs on a client system and logs help you understand or reproduce the system without having to do a remote session (which might be impossible on some firewalled envs).

- Your code crashes without stack trace and you want to understand where to begin the search.

Agree with your overall statement though.

logs beats debugers in asynchronuous mutiple workers/consumers context.

I rarely reach for debuggers, but when I do, they are invaluable. I tend to rely on traces, and I do not consider that "lazy." Traces give me end-to-end understanding of behavior. Usually, that's enough for me to understand what is happening in the moment. When it's not, I use debuggers to understand exactly what is going on in a moment of time. But debuggers are not good at giving me an end-to-end understanding.

This was the only point I disagreed with. Is it really so uncommon for programmers to work on code written by others? Yes, it's true that I don't understand programs written by others. To use a debugger, you can get the actual state of the program at the point you want. To use a log, you'll probably have to first understand the program and then instrument it. For fixing bugs in big unfamiliar systems, I think rational ignorance applies. A surgical strike with a debugger will probably be faster.

I avoid debuggers too, not because I am afraid of them but because I find logging etc works better. However, the fact is that I wouldn't recommend being afraid of them. It is extremely helpful to know how to use a debugger.

In fact I would say if you don't know how to use a debugger, you really have no reason to avoid one. The point of knowing the debugger in part, esp. with more dynamic languages, is to do better debugging in your head.

I've found that debuggers actually help me understand a program. Even when I'm not necessarily trying to fix something, having a debugger to track all the local variables and is a lot easier than trying to keep in all in my head. (Caveat: I'm less of a programmer and more of a data guy who writes some code here and there).

I've found that, due to the prevalence of race conditions in the codebase I'm working in (due to lots and lots of async calls; it's Javascript), the debugger often exacerbates and hides the problem more than it illuminates. As a result, the debugger has ended up as a desperation tool rather than as a first-choice... and even then often doesn't tell me anything useful.

My reaction to this point was that the author is essentially proclaiming, "All you need to do is just have a comprehensive and unabridged knowledge of every single external library and API your code touches, no matter what kind of project it is!" Which, to me, comes across as a bit on the unrealistic side.

Reply on news.ycombinator.com