Introduction

Your leg started to cramp ten minutes ago, but you barely noticed.

The chatter from a distant TV is nothing but background noise...white noise, a gentle reminder of the outside world.

Your only focus is the sound from the strokes of your keyboard…click click click…a rapid-fire staccato of instructions to your machine...

Create Object…insert method…then suddenly, the moment of truth when you test the lines you’ve just added……Success! Great, now you just have to add that one last function…broken! What!! Which line???

Writing code isn't easy, no matter how much experience you have with it. When you get something wrong, some errors are more helpful than others at pointing you toward the mistake. Usually it just takes one obvious re-write to get your program back up-and-running.

But what happens when you’re stuck? Completely at a loss, and staring at 200+lines of computer-speak that seemed very familiar to you just a second ago, and very unfamiliar in an instant. How do you work your way out of the problem? Try these steps to debug your code:

Step 0: Check for Grammar/Spelling Mistakes

Obvious? Sure, but I’ve noticed that 98% of my mistakes come from a misplaced comma or a misspelled “this”. Code is a fickle, unforgiving tool, and one extra letter or missing syntax can confuse your compiler.

(Pictured below: me, for 2 hours, trying to find the extra “.” in my code)

The good news is, most IDE’s will come with features to help you catch errors faster. Personally I love all of the following features: auto-complete, error detection, and color-coding. That last one’s my favorite because it means I can skim through a bunch of orange text strings and notice that little red stinker with the missing quotation mark. But if that didn’t work, ask yourself…

Step 1: What do you know?

It can feel really frustrating when your confidence is dashed by a bright red ‘ERROR’ across the screen. But you knew enough to get yourself here, and that means you probably know enough to get yourself out! So first, you should pick apart the error message and take a mental note of what’s familiar.

“Syntax error…I’ve seen this before, and the last time it was just a typo.”
“Null value….well I know that means that some value is either undefined or it doesn’t exist. Oh, and I also know that the value is probably considered ‘false’.”

Another thing you can try is, if you added more than a few lines of code, then you can isolate them and read slowly line-by-line. Explain to yourself what each of the lines should be doing, or read every word and remind yourself of the definitions. Maybe you forgot the “OR” operator, or you wrote splice() when you needed slice(). Which leads me to the next step…

Step 2: What are you missing?

Here, it could be really helpful to make a list of what you’re not familiar with.

Do you have an idea of which line of code is the problem? If not, check the error message again to isolate the problem. Is there a new word in the error message that you haven’t seen before?

Are you practicing a new concept, one that’s complicated and might be interacting with your code in a way that you wouldn’t expect? Maybe the asynchronous function you're calling has timing problem that you've never seen before.

If that’s the case then you might need to…

Step 3: Research the unfamiliar.

This is, hands-down, my favorite part of coding. Every day you might face a new challenge, and every day that challenge can be an opportunity for growth.

The amount of resources available online for computer programming is staggering. From articles that break down highly-specific edge cases, all the way up to complete Ivy League courses.

Try not to feel discouraged when you run into a new term/concept. Programming languages are massive, and this can happen every day! Instead, try seeing it as an invitation to go down the research rabbit hole. You never know which doors your curiosity could open.

For beginners, reading the documentation is a secret weapon. Every popular framework & library will have its own website that's dedicated to explaining its features and to show you examples. You should use a library's docs as your starting place for research, so that you can build a mental model of how a feature should work, which will give you a better idea of how you're trying to use it.

Step 4: Find somebody who shares your problem.

It’s rare, and especially rare at the beginning of your career, for you to have a problem that nobody’s ever grappled with. There are more than seven billion people on this planet- that’s a lot of engineers!

At this stage I like to get creative with my Google searches. Say I’m writing in JavaScript and I’m uncomfortable with ‘closure’ (and no, we're not asking my ex-girlfriend). Searching for the phrase “Javascript closure” is a good start, but “stackoverflow closure” will give me pages full of community-answered code examples, “r/javascript closure” will include 10+ posts on a wildly popular Reddit community, and that’s not even the tip of the iceberg.

If the first few walkthroughs that you find are dry or poorly explained, then there’s no limit to the amount of information you’ll find online.

Conclusion

No matter where you’re at with your professional development, and no matter what you’re working on, the best thing you can do is keep going. Even if you went through all these steps and you’re still stuck, taking a 5-minute walk outside can usually break down that nasty roadblock.

Follow me on Twitter for more programming tips, and DM me if you have any questions or if you’d like some advice. I hope this helped, and thank you for reading!