The Best Debugging Begins by Asking Yourself These Questions
Don’t start debugging until you absolutely have to. Have you ever been completely stumped by a bug, and then hours later you’re completely un-stumped… and it turns out to be something that seems, in hindsight, dead obvious?
Pairing may make it easier, but before you ask for help, here are some things to do before you fall into that dark, unfortunate rabbit hole.
Don’t go debugging something that isn’t broken. Ask yourself these questions first.
Confirm the issue exists.
Reproduce the issue in the environment it was logged. This gets you grounded in the part of the application that has the bug. You can also inspect the codebase and easily see which files and components will be relevant to look at. If you can reproduce on staging, but not on local it could indicate environment or data issues which are good places to start.
Is it an environment issue?
We forget to configure our environments. One way to not do this is to always check your work. You are most likely refreshing your page as you work, to make sure the feature you are working on is working, but your PR merges, it’s not a guarantee that it works in staging/production. Spend 2 minutes to quickly confirm that nothing is broken and that the basic functionality is there, before passing the ticket on to QA.
- Did your Codeship/Heroku build fail and the code is just not there?
- Maybe you forgot to add an API key to your staging environment?
- Do you need to whitelist your staging URL for your payment processor?
It’s easy to forget all the things we need to do for our environments, and an easy first thing to think about before moving on.
Is it a data issue?
When we code, bugs inevitably arise. Sometimes you create/update data when the code is in a bad state, that puts data into a weird state…which sometimes ends up breaking things later down the line. Get with your QA team or your client to get the exact conditions (user, record, etc) and steps to reproduce the bug. If you can’t reproduce something on your local, it doesn’t mean the bug doesn’t exist. It could mean that there are records containing data that your code doesn’t account for.
Okay, maybe it is a bug…
…So what changed?
Locating relevant files and checking out the GitHub history/blame is a good way to start your investigation. This also gives you a list of other contacts whom you can ask questions about their implementation decisions. On more complex, longer-term projects, it is also useful to look up related issues and requirements. Sometimes a bug is a requirement, and we all just forgot about it.
Well, now you’re in debugging territory.
You never want to waste more time than you need or convince yourself that a non-existent bug exists. This has been especially useful working at Revelry where we run 1 week sprints, and any tool or mental model to get unstuck and maintain momentum is definitely welcome.