At Northcoders, one of the key things we teach our students is a good debugging process. Debugging is a vital part of development, and it's crucial that all our graduates enter the workplace self-sufficient and able to solve their own problems - or at least in terms of coding.

The ways we debug at Northcoders can broadly be broken into two categories: preventing bugs and whacking them.

Preventing bugs

1. Is your code properly formatted?

When starting out, the way you write your code can make it much harder to read, and therefore fix. Proper indentation is key. For every level of nesting, you should indent once more. Compare these two examples:

function addOddNumbers(arr) {
  let sum = 0;
  for(let i = 0; i < arr.length; i++) {
    if(arr[i] % 2) {
      sum += arr[i]
    }
  }
  return sum;
}
  
function addOddNumbers(arr) {
  let sum = 0;
  for (let i = 0; i < arr.length; i++) {
    if(arr[i] % 2) {
      sum += arr[i]
    }
  }
  return sum;
}

Hopefully you agree that the latter is much easier to read, and that if I was to randomly remove a brace from some point in either function, the second would be much easier to debug.

Formatting your code in a readable way makes certain common beginner-bugs, like misplaced parentheses or braces, much easier to identify.

2. Are you using an integrated development environment and linting?

If you're ready to move from experimenting in the browser, and have Node installed on your machine, then setting up an IDE with a good linter can save you all manner of headaches. At Northcoders, we use VSCode and ESLint.

An integrated development environment is simply an application that provides all the necessary tooling for developers, including a code editor and a debugger.

Linting is effectively a spell-checker for code. A linter will read through your code and identify syntax errors that will either break your code or are considered bad practice.

With VSCode, you can add ESLint as an extension. You will also want to install it on your machine. Use the command npm install eslint -g to install it globally. As you should use it on all of your projects, it makes sense to have it as a global install.

Once you've set up linting with strict rules your code will, in all likelihood, become a swamp of red and green squiggly lines. That's good. By hovering over these squigglies, you can find out what you're doing wrong, avoid errors and become a much better developer. Because your linter will improve your abilities so significantly, you should think of it as a firm but fair teacher.

3. Are you using a test suite?

At Northcoders, we do Test-Driven Development (TDD) by writing tests with using red-green-refactor.

If every section of your code is built out using TDD, you should never find yourself in a situation with 100s of lines of code with a bug somewhere in the midst. By following this process, you'll have a much clearer understanding of each line of your code, and should be able to identify problems much more effectively.

Whacking bugs

Before you do anything, can you replicate the error? I'm not taking your word for it. I want to see you run it again. Good. Let's begin.

1. Read the error message.

Error messages get a hard time. Beginners, in particular, dread them. So if you're relatively early on your coding journey, then put aside your animosity. Sit with me a while. Let me try and explain why error messages are misunderstood.

You should think of error messages of tiny pieces of documentation, guiding toward having functional code. Sometimes they can be obscure, or less helpful, but imagine a world without them, where your code failed silently. It's a terrifying place.

Most error messages allow you to easily identify the line that things have gone wrong on, so if the message itself isn't a good enough clue, take a look at the line.

2. Use a debugger.

One of the reasons that we use VSCode at Northcoders is that it comes with a great debugger. This is particularly useful if your program isn't crashing, but is either hanging or yielding unexpected results. By watching events unfold, it becomes much clearer where things are going wrong. Or you could always use a load of console.logs. But the debugger is great, I promise.

3. Google.

If you've read the error message and it's not abundantly clear what it means, Google is your friend. Copy and paste the message straight into the search bar. It's likely that Stack Overflow will be one of the top hits, and we can't recommend it enough. Usually you'll get a detailed explanation of how to resolve the problem, and hopefully increase your understanding of what caused it in the first place.

At this point, it may become apparent there are issues with some of your packages/dependencies. This tends to be the case when the top results are all 'issues' raised on Github, and you can usually resolve them by reading through the chain of comments, or at least find a work-around.

4. Ask for help.

If you've reached this point and feel no wiser, then you probably feel like you're in real trouble. The good news is that developers are a charitable bunch. If you're working alone, you can submit a question of Stack Overflow, and wait for someone to get back to you. If you're lucky enough to know any developers, ask them. The chances are they'll at least try to help.

5. Time travel.

Ah, so you've reached this point. Erstwhile known as the pit of despair. I've read many debugging articles that recommend cutting your losses at this point. Giving up. Walking away. I prefer time travelling. In the vast majority of cases, you'll be able to find a work-around to whatever problem you're experiencing. But save this issue - commit it if you're using Git, and come back to it at a later point in time. As you improve as a developer, you'll often surprise yourself when previously unsolvable problems become easy. Coming back to them is rewarding, and a great way to benchmark your progress.

Interested in what we do at Northcoders? Find out more at https://www.northcoders.com/