Hacker News new | ask | show | jobs
by sanderjd 2600 days ago
A lot of this is appeal to authority. It seems to be a contribution to a growing sort hip- or leet-ness around not using debuggers. Implicit in this seems to be: I don't need a debugger, neither do these famous people, why do you? Aren't you tough enough or smart enough like me and these famous people? You're clearly doing this programming thing wrong.

Well, I use debuggers. I think they're great tools. My feeling is that I'm very happy to use any tool that helps me create, understand, and improve software. When people tell me that a tool that is useful to me in that endeavor is not actually useful, all I can think to do is roll my eyes.

Having said that, something I am very interested in is learning new approaches to interrogate software complexity and solve problems. So, "here are some approaches to understanding and debugging code that have worked for me" from someone who doesn't use debuggers would be interesting to me. But I actually don't see any of that here.

4 comments

I often use a debugger for code with complex control flow and data structures, where you almost inevitably start high level (e.g., Postgres optimizer). I rarely use a debugger when I can fit everything in my head immediately, because the problem is well-scoped, and involves data structures I already understand.

I can quite easily imagine a person that only ever gets to work on problems in the latter category being dismissive of debuggers.

It's a simple complaint that debuggers do not scale.

There is a very outspoken group that claims that if you are not using a debugger, you don't know how to write code. Appeals to authority is exactly what is required to undo the damage those people create.

"There is a very outspoken group that claims that if you are not using a debugger, you don't know how to write code"

I have never seen that

>A lot of this is appeal to authority.

Debugger use is based on the same. Few things in development are not based on idiosyncratic preferences, fads, snake oil salesmen, tradition, or appeals to authority (and those are the math parts of CS). Of the 5 above categories tradition is probably the best and most "scientific" (at least it has stood the test of time).

There is little actual research on such issues (best practices, programming ergonomics, syntax leading to less errors, bug counts per style, etc), and even what little research there is usually flawed, with small samples, and non-reproducible (not that many teams bothered to reproduce it in the first place).

That's why almost nothing is ever settled.

No authority told me to use a debugger, I use them because they work for me. They save me time, help me make money, and make it easier and more fun to code.

If I ever saw a "research study" that said "print statement users have 12% fewer bugs than debugger users" - or vice versa! - I would dismiss it out of hand. What possible relevance could it have to my work? That's not real research, it's just playing with statistics and making up overly generalized stories about them.

That kind of research would just become the "authority" in a new appeal to authority, complete with an infographic!

And nothing has to be "settled", nor should it be. There are many different kinds of programming that require different tools. It's best to be aware of the variety of choices available, and choose your tools according to the particular situation you're in.

>No authority told me to use a debugger, I use them because they work for me. They save me time, help me make money, and make it easier and more fun to code.

Well, I already wrote: "Few things in development are not based on idiosyncratic preferences, fads, snake oil salesmen, tradition, or appeals to authority". So your case would fall under the first option: it's an unscientifically tested personal preference.

>If I ever saw a "research study" that said "print statement users have 12% fewer bugs than debugger users" - or vice versa! - I would dismiss it out of hand. What possible relevance could it have to my work?

It could have all the relevance in the world.

It's not like if you believe strong enough that your preferred methods are the best (or the "best for you"), that you can't still be using an objectively worse method and get worse results...

>And nothing has to be "settled", nor should it be.

Well, if software development wants to be like an engineering discipline, many things should be (studied and eventually settled).

"Works for me" and letting developers improvise and come with their own hodgepodge of practices, preferences, and cargo cults, is how we got into this mess.

I specifically meant that the article was largely an appeal to authority, not that the practice of not using debuggers is itself based on appeal to authority.

Having said that, I find your argument here pretty weird. I use debuggers because they are useful to me, not because I of quotes about them from famous programmers.

>I use debuggers because they are useful to me, not because I of quotes about them from famous programmers.

Which is an equally fallacious reason to use them (scientifically wise) as appeal to authority.

"Useful to me" doesn't mean anything by itself. Something else could have been more useful to you, but without measuring it appropriately (just some personal anecdotes with trying some thing and then another and seeing which you prefer or which seems to you to give you better results, with no real measuring system or rigor), you'd never know. And the industry would never know which direction to invest, and how young programmers should be taught best -- not just about debuggers but about almost everything.

You're making a broader point, which is fine and all. But your comments would be just as relevant if I said, "I pull out shared code into functions because that technique is useful to me". Your point is so broad that it's like a tautology. I really don't lose any sleep over the foundations of my approach to my work being unsupported by rigorous studies. You can feel free to be a science maximalist and run studies on whether pulling code out into functions is actually useful and all the rest of the approaches we've developed over the years. Meanwhile, I'll happily carry on doing stuff that I know is useful to me, like pulling out functions and using debuggers.
I agree. The post was full of appealing to authority that gives me disgust. And I do not like and use debugger.

I am not going to appeal to authority, so I'll describe how I debug. 30% of my debugging is with pencil and scratch paper. 30% of my debugging is with print. And 30% of my debugging is with refactoring. The last 10% of debugging is with profiler. I do use gdb, mostly in scripting mode. I also do breakpoints manually, that goes into less than 1% and get rounded off.

I program with a meta-layer, so that I can write `$print "string interpolated with variables" in a semi-universal syntax and works for all languages that I work with. The meta layer does the parsing and translation. More importantly, the meta-layer organizes the debugging part so it can easily turn-on-off and not to clutter the actual code. Without that, I, too, cannot imagine debug with print will work.

By refactoring, I mean moving the part of code out of the way, or temporary removing or rewrite part of code that I am not sure. This is again, only possible with a meta layer that allows moving parts of code and re-organizing the code without necessarily changing the code. I cannot imaging how one can truly understand complex code without actually probing the code parts by parts.

Then I have seen the new generation of people who grow up with electronic devices and are more used to mouse than pencil. Electronic device can never match the ease and disposable nature of paper and pencil, so I cannot imagine how one could debug by merely navigating the code with an editor.

So while I do not use debugger for debugging, I can perfectly understand how one cannot live without debugger.

>I agree. The post was full of appealing to authority that gives me disgust. And I do not like and use debugger.

Appeals to authority as opposed to what alternative? Untested arguments? Anecdotal personal stories ("I am not going to appeal to authority, so I'll describe how I debug")?

(See my answer elsewhere in the thread for why almost everything is "appeal to authority" or worse in IT anyway).

Alternative to what?

I guess we are implying different objectives here. To convince someone, appeal to authority might be quick effective. But I don't care about convince you or anyone. I care about reasoning. So I show you how I debug, and I say something about my reasoning behind it, and I also think I understand how someone would not work and think the same way as I do. What results I am seeking? If you find there is flaw in my reasoning, blind spots in my thinking, point/comment back to me, it is an opportunity for me to improve. If you find my reasoning makes sense, but the conclusion does not, feedback to me and I may also improve. If you fully agree with me, I may get a boost in my ego. The last one is in my instinct, but I am not sure I really want that.

I will, however, most likely argue back for the potential feedback. Only through arguing back and forth, I truly can understand the feedback and morph into a form that I can use to improve. I often do improve my reasoning even there is no conclusion for the argument yet. It is easy to gain when background and reasoning are provided. So I always provide them, hopefully who ever participates also gain.