If there’s one skill that can help you be a better engineer, a more critical thinker, and a more helpful colleague in 2018 and beyond - it’s debugging.
But, not the kind of debugging you do when you’re starting out as a programmer. The bang-your-head-against-the-computer-until-something-works kind of debugging. That approach is understandable when you’re tired or overwhelmed or scared. But, this is a new year. You are a new you. Let's learn some new skills.
Productive debugging is more intentional. It’s about approaching the problem with a curious and nonjudgemental mindset. It’s about learning new technologies, frameworks, languages, or whatever else might be in your way to find the source of the bug. It’s about communicating what you learn to your peers and stakeholders.
I’ve compiled my favorite tips to help you be a more productive debugger. I hope this helps you on your journey to becoming the happiest and most productive engineer you can be.
Read your stack trace/error message/log thoroughly
Read it fast Read it slow
Take notes
Write down your first guesses at what the problem could be Write down all your assumptions about what is happening or should be happening Ask yourself the debugger’s question Try rubber duck debugging
Understand your tools
Do you understand how to use a debugger? (client & server)? Can you use breakpoints? Can you use grep, ack, or your IDE to find code you’re looking for?
Check out the manuals for these tools and learn about all the commands available to you (this will seriously level you up as a programmer - try it out)
Can you use git bisect to isolate the commit that caused the bug? Can you use git blame to find someone who can help?
Get comfortable walking through code (in your primary language and in random languages or frameworks in your tech stack)
This is a skill that gets better and better with practice, and it reinforces your googling/stack overflow searching skills Use this as an opportunity to learn and understand anything new you come across Develop mental models (or draw diagrams) of all components / state / data flow Try to withhold judgement about the code you read (so you don't get distracted by your own opinions) Assume good intent and practice feeling compassion for the engineers who committed the code or caused the bug
Ask for help when you need it
Use your social capital wisely
Reach out to the person (or people) who could help with a concise description of your problem. Ask them if you can schedule some time with them to go over it. Come prepared to that meeting with all the supporting documentation you have. Be sure to include everything you’ve already thought of and tried (your notes and descriptive commits will come in handy here!) Be polite and thank them for their time
Make time to help others when they need it
This will create goodwill in your team and help you flex your own debugging skills This can pay dividends throughout your entire career
Practice good version control hygiene
Are you trying out a lot of approaches in the code to solve the bug? It's very tempting and easy to get sloppy with commit messages. Each commit is a new idea you tried, or a new assumption you tested. If you don't catalog it thoughtfully you might forget about it and lose those valuable learnings. Consider using git cherry-pick to pick the commit(s) you want to keep on a new branch
What if you figure it out?
Congratulations! You solved it. Be proud of what you’ve learned and accomplished. Write up what you learned and share it with whoever could benefit from it Are you ready to level up?
Write documentation
Update the README, wiki, runbook If the fix looks weird or unintuitive, write up a code comment with an explanation, and a link to the ticket (if applicable)
Write regression tests These steps can often distinguish you as a great colleague/programmer, and could be useful evidence for a promotion or bonus with your manager.
What if you can’t figure it out?
Some days you get the bug, other days the bug gets you. If you're really struggling, communicate that to your stakeholders and ask for more time or for more people to help. Take a step back, think about something else for a while. Come back to it the next morning after a night's sleep. On more than one occasion I’ve dreamed a solution to a problem that bugged me all day...
Good luck and happy debugging :)