I liked debugging more once I realized that the answer always comes as a surprise. Something you believe about your system must not be true, or else the fix would be straightforward. So debugging is like a mystery novel: suddenly seeing what you didn't see before is a pleasure.
I enjoy it when the problem is in my code. I despise it when the bug is in a third party library or utility. That's usually the last place I look and often the hardest to fix (or have fixed).
And sometimes you find a limitation that can't be overcome and you have to think of a totally new way to do everything. For instance, some API documentation says you can get X but the documentation is outdated and half the data is missing. Back to square one.
> I hate debugging. Anyone that’s worked at a desk near mine has likely witnessed my debugging cycle of rage, insight, disbelief, and existential despair.
I love debugging. Debugging is such a fun thing to do - inspect the problem, dissect the architecture, test your assumptions.
Except that House's process is basically equivalent to making a vague guess of the problem and then quickly hacking it into production and waiting to see if anything else breaks.
Watching House helps make debugging less frustrating/painful. I didn't say that following House's example makes debugging happen any better. Occasionally, taking a page from differential diagnosis is probably a good idea, but obviously do whatever makes sense to your situation when it comes to deployment practices.
It's much more than that. First of all, his "guesses" are based on extensive experience and a very deep knowledge of anatomy, pharmacology, etc. Second, whenever he comes up with a hypothesis, he always orders tests to confirm whether he was right (but sometimes, the only available test is to try something on the patient and see what happens). And he's a big fan of Occam's Razor (there's even an episode by that name in the first season, I think), always looking for the simplest hypothesis that will explain the largest number of symptoms. All of these things apply to debugging too.
Same here. These days I work too much on project management and architecture, with occasional refactoring. I rarely get to spend weeks on end diagnosing a really niche bug anymore. New code and architecture is always fun (clean slate syndrome), but I really miss the debugging process. It's what makes programming worth it.
What he is describing is basically an engineering notebook. I prefer paper, even for software, it just seems more natural to me. Plus I can easily add sketches and diagrams then.
I used to keep my design/debugging notes on paper too, but the ability to use "grep" on years worth of notes convinced me to switch to plain-text files. (I still use paper for sketches and diagrams, since I haven't found any software that's anywhere near as good as paper for drawing.)
I've been contemplating seeing how well OCR can handle my handwriting. Fill a notebook, cut the spine off, feed it through a scanner and start a new notebook. That way I get diagrams, and the feel of writing on paper, but I can also grep.
11 comments
[ 4.2 ms ] story [ 9.6 ms ] threadAnd sometimes you find a limitation that can't be overcome and you have to think of a totally new way to do everything. For instance, some API documentation says you can get X but the documentation is outdated and half the data is missing. Back to square one.
Just typing this out is raising my hackles.
I love debugging. Debugging is such a fun thing to do - inspect the problem, dissect the architecture, test your assumptions.
http://en.wikibooks.org/wiki/General_Engineering_Introductio...