Whenever I see this kind of post (which is a decent one, by the way), I really want to encourage people to read what may be the best book on debugging I’ve ever read (and I’ve read a lot of them).
Dave Agans’ Debugging gives nine rules and expands on them with stories and examples to illustrate the reason for the rules. It’s a short book that pretty much every software developer should read. The rules are:
Understand the system
Make it fail
Quit thinking and look
Divide and conquer
Change one thing at a time
Keep an audit trail
Check the plug
Get a fresh view
If you didn’t fix it, it ain’t fixed
One thing that is frequently left off of stuff like this submitted story is keeping an audit trail. Every time I start debugging something nasty (and I work on a compiler, so things get nasty) I take notes in my notebook or, if cut and paste is needed, I fire up a notes.org file and put stuff in there after making a directory to store all the files I’m using for the investigation.
After about 25 years of doing this stuff I haven’t found anything to really add to Agans’ rules, nor have I felt the need to think any are unnecessary. They are really good steps to keep in mind, and it’s very much worth it to read his book.
One thing that is frequently left off of stuff like this submitted story is keeping an audit trail. Every time I start debugging something nasty (and I work on a compiler, so things get nasty) I take notes in my notebook or, if cut and paste is needed, I fire up a notes.org file and put stuff in there after making a directory to store all the files I’m using for the investigation.
I often put my audit trail when debugging to a chat channel. It provides an opportunity to rubber duck debug, and possibility, someone might notice and provide a fresh view.
This reminds me of a talk by Stuart Halloway (transcript) that greatly influenced me. I don’t think you need to know much about clojure to get a lot out of it
Whenever I see this kind of post (which is a decent one, by the way), I really want to encourage people to read what may be the best book on debugging I’ve ever read (and I’ve read a lot of them).
Dave Agans’ Debugging gives nine rules and expands on them with stories and examples to illustrate the reason for the rules. It’s a short book that pretty much every software developer should read. The rules are:
One thing that is frequently left off of stuff like this submitted story is keeping an audit trail. Every time I start debugging something nasty (and I work on a compiler, so things get nasty) I take notes in my notebook or, if cut and paste is needed, I fire up a
notes.orgfile and put stuff in there after making a directory to store all the files I’m using for the investigation.After about 25 years of doing this stuff I haven’t found anything to really add to Agans’ rules, nor have I felt the need to think any are unnecessary. They are really good steps to keep in mind, and it’s very much worth it to read his book.
To add: after you fix the bug, going back to the audit notes can help you find a wealth of open source contributions in your tooling and dependencies.
Checked docs for the right thing but didn’t find what you needed? That’s a doc commit.
Hit an error message that could be improved? That’s a code commit or a UX issue.
The worse the bug, the longer the debugging session: the more opportunities to find contribution gold.
I often put my audit trail when debugging to a chat channel. It provides an opportunity to rubber duck debug, and possibility, someone might notice and provide a fresh view.
Comments on tickets are also great.
I feel like I’m just different than most though. Nobody but me likes to write things down.
Love this advice, especially “Make it fail” and “Keep an audit trail”.
Came here to recommend that same book. It’s an excellent resource
I cannot overstate how useful “audit trails” are for understanding hard problems/bugs.
It’s so easy to get lost in details, to forget previous test results, or even to forget why you were testing something in the first place.
This reminds me of a talk by Stuart Halloway (transcript) that greatly influenced me. I don’t think you need to know much about clojure to get a lot out of it