Oh no! An error occurred, what is to be done next?

Now, every software developer encounters an issue or bug in their code that doesn't always function as we expect it to try and do. Unfortunately, the immediate reaction of most beginners is to travel into denial.

In this post, were going to clarify what debugging is, why we do it and how can we get better at it. Well also reassess why debugging won't reveal all the issues or bugs in our code.

What is debugging?

Debugging is the process of running your code step by step with a debugging tool like Visual Studio, to seek out the exact point where you made a programming mistake. Usually, you'll understand what corrections you need to make in your code, and debugging tools often allow you to make temporary changes so you can continue running the program.

Why do we debug?

There's no magic solution for bugs. Usually, it takes a mixture of googling, logging our code, and checking our logic against what is really happening.

Debugging certainly helps break complex problems into simple ones where the use of a debugger helps to point out what the bug or fault is, where it has occurred, and the way it is caused.

A debugger helps to investigate your code when it gets to the place where you suspect a problem of logic or implementation. You may do the identical thing by adding print messages to your code, but it's a lot less convenient and versatile compared to console.log.

How we can get better at it?

Below, I'll outline some ways I've found useful for debugging projects:

Testing

Another way of debugging your code is by adding code tests. These come in many varieties and include unit tests, integration tests, functional tests, and more. These types of tests are created to save lots of time and check whether the development environment is running correctly. When the tests do not pass, it always indicates a bug that needs to be fixed. The code that failed is not allowed to move on to the following phase until the bugs are fixed and the tests pass.

Pay attention to error messages:

In almost every development environment, if your code fails, you'll likely encounter an error message that explains why your code is failing. Good error messages are helpful and supply you with a file and line number that represents the source of the problem whereas bad error messages are undecipherable and dont add up to anyone but the one who programmed it in the first place. Weve all seen them, usually in very frustrating moments when our production environment is not working properly.

Googling:

As beginners, the possibility that our problem has never been encountered before is pretty low. Its worth leaning on the wisdom of others who came before. If the error message you get isn't clear to you, or you can't figure out why you're getting it, an honest initiative would be to Google it.

One of the many amazing things about software engineering is that the web community is huge. Almost surely there are heaps of people already that have faced the same bug you're facing, which has been solved and explained so other people don't have to struggle with it, too.

Official documentation should be the first thing to check either when you're learning something new or dealing with an error.

Official docs are typically the most complete and updated source of knowledge for any given tool. It sometimes may feel tedious or overwhelming to go through most technical information, but in the long run, I think it saves time.

Debugging Tools:

Debugging tools are usually built into the integrated development environments (IDEs) developers use to write code. There are also debuggers that are included with a number of online web browsers, including Chrome, Firefox, and Opera, for debugging web applications.

Debuggers are utility tools that are designed to allow programmers to create "breakpoints" in code. Once they run code with a breakpoint in it, the code will stop running at the breakpoint which allows the developer to go through the code line by line and examine the variables at each step to determine what went wrong. Using a debugger is the most advanced method you could use and is not needed when other techniques will work.

Check Your Logic:

If weve made it this far, then it's a good solution to go through your code line by line, reading it and explaining it out loud as you go which in software engineering is known as the rubber duck technique.

The idea is to force yourself to truly read your code rather than just assuming you know what it does. In this way, you can check the logic in your mind versus what is actually happening in your code.

Error handling:

Another method of debugging your code is using error handling. Code that does not use error handling will often crash when it encounters a bug. You can use error handling to catch an error and log the error data within a database before it has a chance to crash the application.

Error handling is perfect for finding bugs in a production environment because errors are often collected as they occur and then analyzed later to determine what type of bug is causing them all without causing a bad experience for the software user.

Commenting things out:

Often times you'll end up turning functional code into comments that won't be executed. You begin by commenting out code in the part of the production environment where you think the problem is until the error stops happening. Then you just add each line of code back, one at a time, until the bug shows up again, and once it does, you've pinpointed where the bug is occurring.

Asking for help:

While this is often the last method on the list, it's one of the most important and is commonly overlooked. Most times, you will be working with other developers on the same project who may know more about some of the code than you do. Even if they don't, they may have worked on the part of the application that has the bug. But you won't know unless you ask.

Another reason to ask other developers for help is that after you look at the same code for a while, you may be too close to the problem and choose the wrong route to a solution. Even if the developers you ask don't work on your project, they can often help you find the bug by giving you a fresh perspective.

Conclusion

If you've tried to no avail, or you don't have any colleagues on hand, then it might be time to make your first stack overflow post!

Useful Resources

What are browser developer tools? - MDN Docs
How to debug for absolute beginners? - Microsoft Docs
First look at the Visual Studio Debugger - Microsoft Docs