Debugging with Hypotheses(ayronwohletz.com)
ayronwohletz.com
Debugging with Hypotheses
http://ayronwohletz.com/debugging-with-hypotheses/
7 comments
In sleep, your “background mind” will process all the information you have gathered. I often find that when I come back to the problem the next day the solution jumps out at me.
This happened to me so often and in such striking ways that when presented with a problem now, unless the answer is obvious, I always say I'll be sleeping on it and, no, I won't be solving it today - it's interesting how many people think this is laziness at first, and will even tell you so, but are then thankful the next day when you come up with a creative solution.
This happened to me so often and in such striking ways that when presented with a problem now, unless the answer is obvious, I always say I'll be sleeping on it and, no, I won't be solving it today - it's interesting how many people think this is laziness at first, and will even tell you so, but are then thankful the next day when you come up with a creative solution.
Andreas Zeller's Why Programs Fail is an excellent read for anyone who wants to learn to debug rigorously.
I once asked someone "how is this function used?" He put a breakpoint in it, ran the code, triggered it, and showed me a stack trace. "Here's how it's called." That was a nice specific example, but I wanted an understanding of intent or architecture or something he clearly didn't have. I almost never use a debugger, but my approach was developed in a time of 8-bit machines that didn't have debuggers. That said, I have seen bugs that could probably not be found without a debugger - including compiler errors.
Nice! I wholeheartedly agree - even so much I wrote a thing about this a while back: http://yellerapp.com/posts/2014-08-11-scientific-debugging.h...
The science of debugging. :)
Actually, security hackers often write scientific papers about bugs :)
I think that's the most important point of the article. If you don't understand the code you're fixing well enough to be able to explain what the bug does or why your fix fixed it, you'll have no way of knowing that (1) the bug (and not just a particular limited case of it) is actually fixed and (2) that you haven't introduced additional bugs by fixing the first one.
If you're reviewing someone's code and they can't explain to you how their fix removed the bug (e.g., they just changed random stuff around and the bug "went away"), that's a bad sign.