Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why debugging is all about understanding

futurice.com

Post reply on HN
Print view View original

31–40 of 80 posts

Re: Why debugging is all about understanding

#31

Post by taeric »

userbinator wrote: post #21
henrik_w wrote: post #14

Earlier quoted context omitted.

Had to google the quote about wasting your time debugging to see that it was from "The Humble Programmer". I completely disagree with it! There will always be bugs. It's good to strive to avoid making mistakes, but however hard you try, there will be bugs. It is counter-productive to pretend there won't be any.

It's good to strive to avoid making mistakes, but however hard you try, there will be bugs. That's basically what the quote is implying - you should not be throwing things together and hoping it will work after debugging, but carefully designing to avoid bugs, so there won't be much if any debugging required. An analogy to this can be found in the aviation industry: it's known that pilots do make errors and planes do…

All too often, the "carefully designing" becomes some sort of masochistic ritual where all errors are attempted to be piped through a single tool in the dev chain. Static typing is popular nowdays. As are high level functional strategies.

It is great when these work. Or when you have a high level team that doesn't abuse the system at all and gets things done using these strategies. I have seen too many times where the result is a system that even the creator does not fully understand. Worse, what should be simple changes turn into giant modifications of a Rube Goldberg machine.

Re: Why debugging is all about understanding

#32

Post by ajuc »

jmount wrote: post #28

A quote I have always enjoyed: "Finding your bug is a process of confirming the many things you believe are true, until you find one which is not true." Norman Matloff 2002 http://heather.cs.ucdavis.edu/~matloff/UnixAndC/CLanguage/De...

It's not always 1 thing :)

Some of my "favorite" bugs happened when 2 things were wrong but 1 worked around 2, and then someone fixed one of them.

Re: Why debugging is all about understanding

#33

Post by taeric »

userbinator wrote: post #13
JustSomeNobody wrote: post #5

Writing code is about understanding, also. I've seen developers bang away at a problem for days and not be able to describe how it "works" in a code review. They just tried every crazy thing they could think of until it eventually returned results that looked correct. Don't be that kind of developer. For one, all the other developers are going to make you maintain that code for the rest of your life. Two, never be to…

I agree, understanding certainly can't be emphasised enough - I believe that a good programmer must always be able to understand enough to "mentally execute" - manually stepping through code, possibly with pencil and paper or a whiteboard, and making sense of the results at each step. There are some who argue against this, and their argument is effectively "if the machine can do it for you, why should you need to kno…

I have a similar quip that not many in my office find popular. Basically, if you can't manually test something, what makes you think you can automated the test?

Re: Why debugging is all about understanding

#34

Post by AnimalMuppet »

exDM69 wrote: post #27
megaman22 wrote: post #15

Earlier quoted context omitted.

I've found that it is often impossible to debug multi-threaded code in a debugger. Hitting a breakpoint and single-stepping through code on one thread smashes any other reads that are operating and expecting the thread that is stopped to respond in a reasonable timeline. It can also cover up race conditions, and just generally dork up anything that is time-related. Printf debugging forever! ;-)

If you have a race condition in a multi threaded program, a simple printf is enough to screw the timings and make the bug disappear, it's not at all better than breakpoints and stepping in a debugger. In my experience, the only way to produce safe multi threaded code is to isolate the threading parts and synchronization and stress test them early on. At this point I use a combination of prints, random delays and simp…

> If you have a race condition in a multi threaded program, a simple printf is enough to screw the timings and make the bug disappear, it's not at all better than breakpoints and stepping in a debugger.

If you have a race condition in a multi threaded program, a simple printf may be enough to change the timings and make the bug disappear. But a breakpoint and stepping in a debugger is guaranteed to completely change the timings (unless your timings are on the order of minutes).

Re: Why debugging is all about understanding

#35

Post by duggan »

JustSomeNobody wrote: post #5

Writing code is about understanding, also. I've seen developers bang away at a problem for days and not be able to describe how it "works" in a code review. They just tried every crazy thing they could think of until it eventually returned results that looked correct. Don't be that kind of developer. For one, all the other developers are going to make you maintain that code for the rest of your life. Two, never be to…

> For one, all the other developers are going to make you maintain that code for the rest of your life.

Ah, if only that were the case. In reality, developers move between jobs, and bad code always becomes someone else's responsibility eventually.

Instead, it's better to understand that as a professional you should be - if not proud of your results - proud of making the best of a bad situation for whoever will inherit your codebase, be that your future self or a colleague.

Re: Why debugging is all about understanding

#36

Post by yoz-y »

dr_zoidberg wrote: post #24
mattmanser wrote: post #22

Earlier quoted context omitted.

1. Can you consistently replicate the bug? 2. Are you sure you can you consistently replicate the bug?

Those should have been 0 and 0.1 in his list. Agree with all 12 points. My little grain of sand: use all the tools available to avoid bugs: a good IDE and/or code linters/inspectors can work wonders on a codebase. I've seen people still programming with "just a text editor" (not Sublime, vi, emacs or any powerfull text editor, I'm talking little less than Notepad with syntax highlighting) telling you "it's just I don…

I'd even dare to say that it is better to shove Vi/Emacs experience into a real IDE rather than the other way around.

I really like Vim, I use it for almost everything, however when I am working on a large C++ codebase I tend to use an IDE that has full support for visual debugging, code navigation and so on. I am always amazed when some more experienced programmers than me spend valuable time grepping files and using GDB on command line.

Re: Why debugging is all about understanding

#37

Post by AnimalMuppet »

spiralpolitik wrote: post #25
userbinator wrote: post #13

Earlier quoted context omitted.

I agree, understanding certainly can't be emphasised enough - I believe that a good programmer must always be able to understand enough to "mentally execute" - manually stepping through code, possibly with pencil and paper or a whiteboard, and making sense of the results at each step. There are some who argue against this, and their argument is effectively "if the machine can do it for you, why should you need to kno…

This scales up to about 10-15 lines of code before it becomes impractical in most modern imperative languages. Functional languages due to their higher level constructs get better mileage out of the technique but there is still a small practical limit to the technique. It also doesn't work if your team isn't co-located.

What? No. If you can only scale that up to 10-15 lines of imperative code, you're writing imperative code completely wrong.

Re: Why debugging is all about understanding

#38

Post by TheCams »

scott_s wrote: post #30

I wrote about the relationship between debuggers and logs a while back: http://www.scott-a-s.com/traces-vs-snapshots/

Totally agree with that. In my previous company we were always working with dumps for asserts/crashes and when I started working in my current company I was confused that they mainly use logs. Now I can't go back to debugging without logs. Using dumps is like looking at the consequences, looking at logs is looking at the causes.

Re: Why debugging is all about understanding

#39

Post by k__ »

Debugging can be fun, too.

If often found some bugs in a reporting software, that showed the people wrong numbers for years.

Or if something needs to be re-implemented, say for performance reasons, you get the algorithms and notice that the old version wasn't only slower but also wrong.

When this happens, I start to question if the people really "use" the software in the first place. Or if they just get some wrong sens of safety from it, which calms them, but the underlying system is mostly random and they could simply make up their own numbers.

Re: Why debugging is all about understanding

#40

Post by ams6110 »

Also a couple of tips for the beginning programmer:

* You've almost certainly not found a bug in the compiler or libraries or language runtime (somewhat more possible if you're using alpha, beta, or dev versions of something).

* Your CPU, memory, or other hardware are not defective.

* You are not experiencing cosmic rays flipping bits randomly in your data.

* The problem is most likely to be a mistake in your code.

I have worked with programmers who are quick to jump at the most unlikely explanations for bugs, and it's a very timewasting way to work.

Post reply on HN