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.
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.
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).
Please consider using Brave and adding me to your BAT payment ledger. Then you won't have to see ads! (when I get to $100 in Google Ads for a payout, I pledge to turn off ads)
Also check out my Resources Page for referrals that would help me.