June 09, 2018
Ever lose a quarter in the ball pit at Chucky Cheese? That’s what debugging front-end code can feel like. Diving in again and again, blindly reaching only to come up empty-handed.
Over my time working on front-end code I’ve come up with a few methods to make debugging slightly less painful; in this four-post series I’ll share some of the most valuable tips and tricks I’ve picked up to help with the debugging process.
In this post I’ll deal with an overall approach to front end debugging, while the following posts will go into greater depth on Chrome Dev Tools as a debugging tool.
You’re not sure what could cause this bug to happen and have no clue how to even begin it.
Take a methodical approach. This is an essential mindset to bring to the table when troubleshooting bugs. The behavior you’re seeing is not an accident; something is causing it to happen. Break down what is happening in detail: what is happening, in what order, and how is it changing state/properties?
Isolate the problem. You want to be working with as few lines of code and variables as possible. Use the process of elimination to focus in on the area that is causing problems. Sometimes it helps to create a codepen/jsFiddle/etc to reproduce the problematic lines.
Just trying to see what’s going on is taking forever.
Learn your tools. Browser developer tools have come a long way, and chances are if you’re trying to see something, there’s a way to do it in Chrome or Firefox dev tools. One of the best investments you can make as a front end dev is to take an online course or two in dev tools.
You’re not sure if this is a framework problem, a logical problem, or just a cruel practical joke.
Google searching the console error didn’t immediately fix your problem
Up your google-fu. Learn to be more specific with your google searches- use an accurate description of the problem and search modifiers.
What you’re dealing with is nowhere in the documentation
Get comfortable going beyond documentation into source code. Some of the biggest ‘aha!’ moments I had early on in development were when I realized I could just look into the source code of an application and discover things that were completely left out of the documentation. Documentation is great, but you can’t always trust it to be comprehensive.
You spent hours on a problem and feel like you’re going in circles
Rubber duck or replicate. Sometimes talking your way through a problem- either to another person or a synthetic waterfowl- is the best way to trigger a solution in your mind. I can’t tell you how many times I’ve solved a problem halfway through explaining it to someone else!
You beat your head against the wall for 3 hours instead of having a 30-second conversation.
Know when to take a break. This goes right in line with rubber ducking; sometimes you just need a change in scenery and a little bit of mental space. I’ll often step outside and take a quick walk around our office building if I’m struggling with a tough problem. I’ve even had answers to coding problems come to me in my sleep!
You have a hard time understanding all the moving parts
Ask for help. This was especially tough for me as a junior developer- I wanted to make sure I was looking into problems enough on my own before bringing something to one of our leads. There’s nothing wrong with digging in on your own, but make sure to avoid wasting too much time when a conversation with the right person could give you an answer right away.
You followed all of the above steps and still ran into a crazy edge case that took you all day to get through.
Truth is, no matter how well you approach things, debugging is hard. Sometimes weird things happen, and you’ll beat your head against a wall for hours in order to find a problem. These are the days that make development frustrating… but the feeling when you find the fix to the problem is also what makes development so fun! So go home, relax and recover, and live to fight another day!