Why doesn't my code work?

After you've been writing code for a while you start to notice things. Maybe you have a picture that's a little too far left or the price you're getting for a shirt isn't right. The one skill you have to have to fix those bugs is the ability to debug code.

It could be something as simple as a missing letter in your variable name or it could be something as complex as the dll missing something. Even though there are a lot of things that could be wrong, odds are that it is something pretty common. I'm going to give you a few steps you can take to debug code efficiently.

1. Make the error happen again.

   • You have to make sure that you can reproduce the error or else you won't be able to fix it. As soon as you notice something is wrong, stop and trace your steps backwards. Figure out exactly what you did to make that error happen and do it again. Now you have a starting point.

2. Look at the error message.

   • Open your browser and look at the developer tools by pushing F12. Look at the console and see if there are any error messages. If there aren't any error messages, then you're going to have to dig deeper. I'll cover that in a different tutorial.
   • Now that you know the error message you technically know what's wrong. If you don't understand the message, just Google it. Stack Overflow is a great place to start looking. You might have to read through a few forums, but you'll eventually find an answer that leads you in the right direction.

3. Start tracing through the call stack.

   • Once you have the error, you know what line the error happens on. Put a break point there and start tracing the call stack to the root of the error. The call stack shows you everything that has happened in the code up to the point that it breaks. This will help you fix the real problem is instead of just slapping a band-aid on the place that it broke.

4. Find where you think it's happening.

   • After you've been through the call stack you should have a place in the code that you want to start checking. Take your time and read through your code. That's the only way you'll get to the root of the problem. It might take a while to find the root, but you have to have a good starting place.

5. Check for syntax errors.

   • Start looking for any syntax errors. Check if you missed any semicolons, see if you have any spelling errors, and look for any missing commas, dashes, or any other punctuation. These types of errors are the most simple to make, but they can be the hardest to find. Most developers make the mistake of rushing through the syntax. Take your time and make sure this is right. It'll save you a lot of headache later.

6. Check for logic errors.

   • These are tricky little buggers. They might not show up until your code is already running because of bad data. You could be comparing the wrong values and not even know it. Make sure that all of your variables are the right type for what you're using them for.
   • As an example, you might want to discount a price and you need to do a little math to make it work. You don't want to be subtracting strings when you should be subtracting numbers. Finding logic errors takes some patience and a little experience. Just go through your code with a fine tooth comb and you should be able to find these errors.

7. Check for environment errors.

   • In most cases it won't get this deep, but it doesn't hurt to make sure your environment is setup right. Are you connected to the right port? Are your passwords correct? Did you change the way your project handles certain packages? Sometimes updates can change your settings so it's a good idea to look here too.

8. Run your code after any changes you make.

   • Whenever you make a change to your code, always run it to see if the error is gone. It's important to track what your changes do so you know whether they work or not. The worst thing (and most common) is to "fix" your code and not know why it works. Sometimes changes cause more problems too. That's why you need to see what happens every time you tweak something.

9. Get up and walk away.

   • If you haven't figured out the problem by now, get up and leave it. Go walk around for a few minutes. Drink some water or get a snack. When you've been working on a debugging issue too long, you start to lose track of what you're doing. If you've been trying to debug code for over 30 minutes, just leave it and come back a little later.

10. Repeat 4 - 9 until the code works AND YOU KNOW WHY.

    • Debugging code is an iterative process. You'll probably go through this cycle at least twice and that's on the low end. So don't feel bad if you haven't figured it out in 10 minutes. It takes a while to debug code. It actually takes longer to debug code than it takes to write it.
    • You also need to understand why your code works after you debug it. If you don't know why your code works, then you'll have a bug later on down the line. Most developers aren't 100% sure why their code works, they're just happy it works. But unless you want to get stuck in an infinite loop of debugging code, then try to get it right the first time.

11. Go get help.

    • If all else fails, get up and go ask someone else to come look at your code. You can do this on Stack Overflow or any other programming forums, but if you are working with other people on a project then go see if they have a few minutes to come look for the bug with you. As a rule of thumb, you should try to debug the code on your own for at least 30 minutes before you go ask for help.

It takes a lot to debug code, but it's the best feeling in the world when it finally works again. No programmer is error-proof. Even people who have been doing this for over 20 years still need to debug their code. You learn how to do it better and faster the more you work at it.

---

Hey! You should follow me on Twitter because reasons: https://twitter.com/FlippedCoding

Comments

[Jan Wedel]

There are some useful tips in there, but the most important step is missing. Write an automated test to reproduce the bug before fixing it. This should replace step 1). Then, step 8) would be TDD, rerun the test and change your code until it works.
This is really important to make sure you won’t have any regressions. A good test suite is especially important when trying to find a bug. You usually try a lot of stuff, changing code here and there. From time to time, you forget to revert something and there it is, your regression.