Why debugging is all about understanding

Post by rumcajz » Fri, Aug 07, 2015, 6:55 AM UTC

Post by yuliyp » Fri, Aug 07, 2015, 9:45 AM UTC

mwcampbell wrote: post #18

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…

But how can I mentally execute code if the whole point of the code is to interact with a third-party OS facility or application that's closed-source and therefore opaque? In that case, my mental execution of the code will depend on a mental model of the third-party component that's probably incomplete. Might as well just let the machine run the real thing.

Post by ionforce » Fri, Aug 07, 2015, 6:52 PM UTC

vog wrote: post #55

mhomde wrote: post #12

Over the years I've become more and more convinced that debugging has done a lot to develop my problem solving skills and analytical thinking in general. It's like being a full-time modern times Sherlock Holmes with the crime scene and tools neatly at your disposal. Usually breakpoints and stepping through code solves things pretty easily but some bugs can be real stumpers. Here's some of the tools I tend to use: 1.…

Regarding 7, I think you should explicitly mention "git bisect" and similar tools. (Or, are you doing that step by hand?!) For me, when I run out of ideas, "git bisect" is the most efficient debugging tool. On success, it allows me to pin down the exact commit that introduced the bug. It is very fast to do (binary search), and on success it narrows the bug down to a relatively small amount code to check. Of course, t…

Post by Licenser » Sat, Aug 08, 2015, 1:10 AM UTC

mwcampbell wrote: post #50

bcantrill wrote: post #42

While it's great to see more attention brought to debugging, some of this is just (for lack of a better word) insane. e.g.: For searching in space, most programmers have done binary-search with commented code: comment out or bypass half of your codebase. Do that recursively until you nail down where (at which file, which function, which lines) the bug lives. No, most programmers actually haven't done this for the sim…

I listened to your DockerCon talk on debugging. So in a server that can handle multiple concurrent requests (e.g. a web application server), should each unhandled exception abort the whole process (after delivering something like an HTTP 500 to the client) so the developer can do postmortem debugging on a core dump? That would cause all other in-progress requests to be aborted too, unlike simply logging the exception…

Post by ectoplasm » Sat, Aug 08, 2015, 4:40 AM UTC

rjurney wrote: post #69

ectoplasm wrote: post #61

Earlier quoted context omitted.

Sorry, I'm kind of confused here. Why is the approach I'm defending considered random and not based on data? Is the generation of random hypotheses in general considered unscientific? What about fuzz testing or pharmaceutical R&D? What is the precise difference between hypotheses and assumptions in the context of the scientific method? What is the difference between the presence of a small portion of code being respo…

Because it seems you're making an assumption about the problem being reproducible and identifiable by running half the code. I've never found this to be the case. Ever. Its a strange idea. Where does this come from? This isn't a hypothesis based on data, it is an assumption. And a bizarre one.

  main() { a(); b(); }