Comments

Becoming A Black Belt JavaScript Debugger

Have you ever struggled to debug an issue with your code for hours, only to have it solved by a friend in minutes? Maybe you’ve spent hours searching stack overflow only to realize the problem was a fairly simple mistake. Whatever the case – we’ve all been there. Actually writing the code is only a small piece of what goes into being a professional developer. Debugging the code often takes as long or longer than writing it!

Despite this, developers typically spend very little time talking about what it means to become good at debugging, and what skills you need to get there. Once a piece of software gets large enough, bugs are inevitable. If you can become the person that reliably hunts down and solves bugs – you will be indispensable.

In this article, I’ll give you an overview of the best debugging techniques, starting with the simplest but also covering some of the best-kept secrets in JavaScript debugging. I’ll also cover how you can develop the mindset necessary to become a great JavaScript debugger.

Console Debugging

If you’ve been writing JavaScript for more than a few minutes, you’re probably familiar with this technique. Essentially, you just drop a console.log($var) statement in your code to get a better understanding of what is going on. Common use cases are logging out $this, $data, as well as errors.

A lot of people frown on console debugging, but the vast majority of the time, this is the debugging strategy that I reach for. It’s not sexy to talk about, but that’s precisely what makes it so great. It’s dead simple, flexible, and provides a good sanity check. That said, this strategy does not handle the more complex bugs that you will no doubt encounter.


console log debugging meme

If you find yourself with console.log littered all over your code, it’s probably time to reach for a more “robust” strategy.

Break Points

I’m embarrassed to say, but I had been programming for quite a few years before I found out about this one. It blew my mind. You can just toss the line “debugger;” into your code, and when you hit that line when loading the page (your dev tools must be open!) it will “break”.

hello world debugger code snippet

In this case, that means the loading of your web page will pause at the point where you set the breakpoint. It also means that you have the ability to step through your code line by line, to see where the problem is occurring. You can see all of the variables in scope as well as the call stack, and access them in the console down below.

break point debugging in the browser

Breakpoints can be set directly in the browser. This is done by opening the developer tools, navigating to the “Sources” table and then clicking in the margin (next to the line number) of the line you at which you would like to break. Then trigger the line of code – and you’ll trigger a breakpoint.

It’s still light-weight, but way more powerful than sprinkling log statements throughout your code.

With a little more effort you can set up your dev environment so that breakpoints can be set in VSCode (or your IDE of choice) just by clicking into the margin on the line where you want to break. It’s probably not worth setting this up on a short-term project, but if you know you’re going to be working on something for more than a month, it’s probably worth taking the time to set it up, to make it even easier and faster to debug your code. This video will get you started if you’re interested in the process.

You can also set up XHR (network request) breakpoint, DOM breakpoints, and Event listener breakpoints.

Network Tab

The next best JavaScript debugging secret is the network tab. You can get there by opening the development console in chrome and navigating to the Network tab.  After you reload the page, you will see a bunch of rows in a list, each corresponding to a network request.

It can seem a bit overwhelming at first, but I promise it’s not all that complicated. This will allow you to inspect all the requests and responses to see the status-codes, method type, and if the response was cached. There’s so much information in one place, I often like to open the network tab in its own window when I’m looking into something.

network tab debugging

If the status code for a request is a “200” – that means the response was returned successfully. You will also probably see some “304”s which means that the asset was cached. If you want to disable caching for a request – there’s a checkbox for that (see screenshot above).  If you see 4xx or 5xx errors – these are error codes.  This is a good indication that these requests might be where your problems are coming from.

This video serves as a great intro into all of the valuable insights you can get from looking at the network tab. If you’ve opened the network tab before but never spent much time figuring out what all of that stuff means, I highly recommend taking the time to learn. It will definitely level up your debugging ability.

Black Belt Debugging Mindset

Many personal finance bloggers like to tout that becoming wealthy is mostly about creating the right mindset. Debugging is no different. The first key is believing that you can and will get to the bottom of the issue. It sounds cliche – but that’s because it’s true.

Another classic technique is “Rubber duck” debugging which is the process of trying to explain your code and thought process to a rubber duck. This might seem kind of ridiculous at first, but it really works! The process of trying to put your thought process into words clarifies your thinking and forces you to fill in the gaps with clear logic (or notice your mental error).

Probably the hardest part about debugging is that the computer is always right. Learn to accept this. Debugging is hard. Don’t expect to solve a problem right away.

I love this podcast on debugging stories. To be a great JavaScript debugger – you have to fall in love with it. You have to have fun with it. If you’re anything like me you’ll be laughing out loud about how absurd some of these bugs were. This podcast is a must for developing a great debugging mindset.

Summary

  • Console.logging is not bad! Use it liberally (but with some moderation)
  • Breakpoints and the network tab are your friends for tougher issues.
  • Read this to better understand why “Rubber duck debugging” or “Explain code to your wife” works so well.
  • Listen to this podcast for pure entertainment and learning to love the debugging journey.

Thanks for reading. If you liked this post, please share it.

If you want to learn more, and level up your javascript skills, check out this great deal on Mosh’s bundle of JavaScript courses.

Comment below with your best debugging story!

Hi, I’m Taylor. I’m a software engineer at Thumbtack. I care about helping others learn to code so they can find a job they love which is why I love working with Code With Mosh. I also write about life @ https://taylormilliman.me.
Tags: , , , , ,

Leave a Reply

Connect with Me
  • Categories
  • Popular Posts