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.
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.
If you find yourself with console.log littered all over your code, it’s probably time to reach for a more “robust” strategy.
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”.
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.
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.
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.
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.
- 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.
Comment below with your best debugging story!