Debugging Steps

Some colleagues went to Prarie Code 2017 this year. I got to go to NE Code earlier in the year. As they recapped their conference at work, on of the session hints that caught my eye was “Everything I Needed to Know About Debugging I Learned in Elementary Physics” by Nate Taylor from Aviture .

I’ve been using his hints a lot this week as a framework. The key is to write them down on paper or in notepad. Then when I’m still stuck or get distracted, I can come back to where I was at and not waste as much time. I also like this because it’s reminiscent of the scientific method. Sometimes with an obscure bug, all you have is a theory to start on.

1. Draw a picture
   1. the bug report, how was it created
2. What is known
3. What is unknown
4. pick a starting location
5. write a failing unit or integration test(s) to prove that it is broken and test out your assumptions.

Then repeat as necessary based on what you learned. Hopefully this will help you like it has helped me to focus and fix bugs faster.

Don’t forget to write a test to cover that bug so it never comes back!

There are known knowns and known unknowns as Donald Rumsfield said that at times applies to complicated software bugs.

The importance of automated tests

This becomes much easier if you already have automated test coverage. The first 4 steps will still help you, but now you have a safety net and quick feedback in case you break something. Add the test to cover the bug, make sure it breaks, then fix the code. You’ll never have that bug come back and bite you again!

You could call this #TDD (Test Driven Debugging).

Steve Smith has some great tips. Listen to his weekly dev tips episode 37 (and then start from the beginning and listen to all of them!).