Oh Yes, Another Bug… Come On In!

Ping! There goes Slack again.

“Hey, if you have a minute, could you take a look at this ~ bug ~?”

Programming is constantly evolving. If you don’t already, you need to learn to love learning. Anyone can be taught the differences between ES5 and ES6, how syntax differs between JS frameworks, even a new programming language…it’s not about what you know, but the strategies you’ve developed to know the things you do know now. These strategies are the root of what you bring to your next interview, what you teach to someone else in your class, and what you are capable of learning for the remainder of your career.

So, you’ve found a bug in your code. Again.

What have you already done about it? What are you planning to do next, and how can I assist you?

Here are a few tips and tricks for learning to debug your code:

• Embrace it — Congrats, you know your app well enough to find a bug! And, you’ve encountered a new learning opportunity. Although I’d love to write code that is forever bug-free, it’s not a realistic expectation to set for a software engineer who is learning. So, what do I do? My first reaction is “ugh, what now”, followed by “okay, time to figure out what went wrong.”
• Compare expectations vs reality — Upon that first reaction to seeing the bug, why are you surprised to see what you see (or, my favorite: what you don’t see)? As described in something like a user story, what is the difference on the UI? What is the user unable, or able, to do? Write it down. Better yet, explain it to your dog!
• Run the test suite — Test Driven Development is here to stay. If you have a test suite up and running with unit and integration tests, run the test suite to ensure the code you think works, still works. This is a great way to ensure that existing features are not affected by your bug, or that you catch where the bug may be affecting them regardless of manual testing.
• Check for errors — Your console is your best friend here. What is that big red error message stating (or yelling, if you will)? Don’t ignore it. Use it. That’s right; copy and paste that error into Google. What does Stack Overflow have to say about it? Browse Stack Overflow with purpose and ask yourself: “Is this person describing the problem in a similar context?”

• Use the Chrome Dev Tools — Use it to pinpoint that line of code where the error occurs. Step through the suspicious functions. If you’re using a framework such as React or Vue, install the plugin or extension for that particular framework. Dig through the component tree. View state updates and function calls in real time. It is your browser’s source of truth.

• Be specific — It’s okay to Google. You’ll be Googling for a while. Always search for solutions or insights by being specific. Are you asking a Node.js question? Great, mention the version number. Are you experiencing an issue in a specific file generated by create-react-app? Mention that file name. The more information you can provide, the more accurate and helpful your results will be.

At this point, you should have a description of what should be happening, a description of what is actually happening, more context regarding any errors, and some visual feedback from the Chrome Developer Tools.

At this point, you might feel ready to jump into your code and fix the bug. Have you made good use of your resources? If so, then go ahead and work through some possible solutions.

“I’ve tried x and y and even z…feeling pretty frustrated. What should I do?”

• Restate the problem — What do you really know about your bug? Can you identify exactly when it occurs? Can it be easily reproduced?
• Take a break! — Go look at a tree, as one of Turing’s Front-End Instructors suggests (Thanks, Leta!).
• Acknowledge that it’s fine (really) — Debugging takes time, especially if it’s a huge, feature-breaking bug.

Still stuck? Can’t think of where to go next? Ask for help!

“Hey, if you have a minute, could you take a look at this ~ bug ~?”

Is now replaced by:

“Hey, if you have a minute, could I talk through this[super thorough description of the bug]bug with you?”

Check out how the dynamic shifts with the change of phrasing. Now, you are ready to show that would-help-with-anything teammate what you know about your bug, rather than placing the responsibility on the person on the receiving end of your Slack message. You didn’t panic-send your message; instead, you spent the appropriate amount of time digging into your bug and you’d like to bounce some ideas off of your friend. It’s on you, and sometimes you even figure out your next move as you describe the bug!

Here’s what to include in that message:

• A description of the bug — Remember all that time you spent figuring out what you expected to see vs what you actually see? Let it shine here. Explain how the bug fits within the context of your application, and assume your teammate is unfamiliar with the task.
• What you’ve tried — Give them a list of what you’ve done until this point in your debugging process. What did you try, and is there a resource associated with that attempt?
• Screenshots!!! — If your home screen is cluttered with screenshots, go ahead and use some of them to your advantage! Take screenshots of the error message in its entirety, what the DOM looks like before and during the bug, and the affected file’s lines of code. The more information, the better!
• Why you’re stuck and reaching out — Describe the point at which you’ve left off in your debugging process. Where are you stumped, and what exactly do you want to talk about with your teammate?
• Anything else that’s helpful — You know your code and your teammate best!

With debugging, comes learning. Eventually, you will fix the bug and move on…until the next bug comes around. I challenge you to welcome that next bug, as you’ll either A) have run into it before and have an idea of how to solve it, or B) use the strategies outlined in this article to reach a solution and learn something new. As you grow in your career, sometimes bugs will present themselves as points of frustration, as annoyances, as roadblocks — but they will always present themselves as learning opportunities. Embrace that!