Kode Vicious at ACM Queue offers a rationale and some tips on keeping a debugging log.

What you really want is a way to remember what you were doing when you were doing it, and debugging is one of the best examples of this. Nothing is more annoying than to come back to a problem you were working on and not remember what you had already tried. Having to redo your experiments and measurements again is a hair-tearing experience, which is why I started shaving my head years ago - it's far easier than tearing the hair out. What is important is to realize that you are doing experiments and taking measurements, and that will lead you to your answer.

Real scientists, as opposed to lame hacks who claim to be scientists, know how to formulate ideas - called hypotheses - and test them. They write down each hypothesis, then describe the experiment and the results. They keep all of this data in logbooks or notebooks. One of the earliest examples of a logbook being used in this way by computer scientists was when Grace Murray Hopper recorded the first bug, a moth found in a relay of the Harvard Mark I computer, in the logbook that was kept in the machine room with the computer. Gone are the days when you can debug a program by pulling a moth from a relay, and, well, good riddance - I mean, ick! It is still a fine example of how one should proceed when trying to figure out a complex problem.

Speaking of examples, I will present you with one of my own from a kernel debugging session I was recently trapped - er, I mean involved - in.

I'm not detailed oriented enough (and perhaps not smart enough) to be good at coding, so I frequently find myself lost in tangled nest of error messages, patches, dump files, and—possibly worst of all—half-assed bits of code I wrote in an attempt to resolve the problem but that, because I can't remember exactly what I was trying to do when I wrote them, only add to the confusion. But several years ago I noticed that the more successful linux people I worked with tended to keep obsessively detailed logs of what they were doing when installing, patching, or debugging things. They entered dates and times, system versions, chunks of text copied from error messages, and other information into a log while they worked. Most of it they never used, but when they ran into a problem, they read back over their notes to see if they could find any clues. And sometimes, they did.

So I started keeping a system install and debugging log, either in a paper notebook or in a file on the system I was using. I've not succeeded in making myself obsessive enough about it, but it's a start. Did it solve all my coding issues? Not by a long shot; there's more involved in good programming than simply taking a lot of notes. But does it frequently rescue me when I've gotten myself into a corner? Frequently.