The debugging secret I wish they taught in school
Published: 2024-06-12 07:36:06

This [blog](https://www.letterstocoders.com/p/the-debugging-secret-i-wish-they) was originally published on Substack. Subscribe to ‘[Letters to New Coders](https://www.letterstocoders.com/)’ to receive free weekly posts.

As a Computer Science student, I hit a bit of a hiccup while I was working on my first slightly bigger project involving data structures and pointers. It took me a day to write the program, but the program kept crashing.

After spending a few hours debugging, I gave up and decided to rewrite the program.

Spoiler alert: **it was a huge mistake**. Here’s why — and what it taught me about being a good programmer.

## The do-over

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/piynon94o28ap34icd5t.png)

Rewriting my program took another day. It wasn’t a huge program, so redoing the effort seemed reasonable. I’d had no luck finding the bug in my first iteration, so I figured that taking the process mindfully from start to finish would help me ensure I had a functional program.

The result? **A different bug.**

This time, the program didn’t crash, but it wasn’t behaving as I expected it to. This was incredibly frustrating. The worst part was that there was now a bug in the part of code that had been working fine before.

For a moment, I considered combining the code from my first and second attempt to create one functional program. But this Frankenstein-approach would require me to understand where the bug was in each program anyway, on top of ensuring two different instances of code worked cohesively together. I’d already exerted duplicate efforts to write a second program, and without a doubt, this approach would only overcomplicate my matter.

The only solution was to go back to debugging my very first attempt, so I did — and eventually I was able to make that first program run perfectly.

While I wasted valuable time rewriting that program, I learned an even more valuable lesson: I should have spent that time debugging instead.

## Don’t start over. Debug.
Debugging can be stressful. It can even be a little disheartening. You can spend hours or days in confusion and frustration, only to find that the bug was under your nose the entire time. But even obvious mistakes like this are commonplace, and there’s no shame in them.

All developers — no matter how experienced — face bugs on a constant basis. So, the sooner you brave the debugging process, the better.

Even still, when you’ve written a relatively small program and get stuck on a bug, your knee-jerk reaction may be to write it from scratch, hoping that you’ll get lucky and come out bug-free.

But there are 2 reasons you shouldn’t do the do-over.

**1) It’s impractical (even unrealistic).**
You simply won’t have the option of rewriting programs as they get bigger. Once you start your first job, you’ll be making changes to big codebases of **millions of lines of code**. You simply don’t have the luxury to rewrite code around bugs when they happen (especially while pressed against deadlines).

Second, and most importantly…

**2) By starting over, you’re not building the muscle of debugging!**

Great developers don’t write perfect code, but they are very skilled at debugging.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1c2q5h8ws1cv458e2sly.jpg)

Debugging is part and parcel of learning to code. Bugs are simply inevitable. They can arise from various causes, whether they’re your own errors, incompatible codebase changes, or from third-party dependencies. As a result, you can** expect to spend more time debugging** **than writing code** throughout your professional career.

As it turns out, debugging was a significant part of my job at Microsoft, where I focused on debugging process crashes for a few years. I was eventually able to create automations that allowed us to scale this debugging process as we scaled our services. It would’ve been impossible for me to manually debug these crashes on my own once we scaled, but I was only able to automate this process after I gained experience and understood the patterns from years of manual debugging.

The better you get at debugging quickly, the more successful you’ll be. So, work on your debugging skills. It takes time and effort. But whenever you find a bug, you learn a few things.

## 6 trusty tips for debugging
At first, you may hate debugging. But it’s a skill you will strengthen over time. Eventually you’ll agree that there’s no better feeling than finally fixing the bug in your code.

Here are some debugging strategies to explore:

1. **Describe the problem aloud to yourself** (or to a rubber duck, which is what devs call rubber duck debugging). Narrating your thought process can often reveal assumptions you made or details you missed.

2. **Narrow down the area where the bug is occurring.** Being able to “zoom in” on the problem area is like shining a flashlight in the darkness, and seeing exactly where you need to tend your code. It’s the best debugging muscle to develop early-on. You can either do this with a critical review of your code or other strategies like print/log statements.

3. **Use print/log statements.** This involves placing print statements in various points in your program to see where the problem is occurring. For example, you can place four print statements throughout your program. If the program crashes or gives an undesired output between statement 2 and statement 3, you know your bug lies between those particular statements.

4. **Use a debugger.** As a beginner, using a debugging tool can help you while you’re writing small programs in your own environment. Just keep in mind that it’s not a long-term strategy, as most debugging in a professional environment is done after the code is already written, when the only helpful strategy would be using print statements.

5. **Ask for help if you’re stuck.** There’s nothing wrong with asking for help, and the developer community, whether online or through a friend, is often happy to provide feedback.

6. **Sleep on it.** Take a break. You might be code-blind (or concept-blind) after trying to force yourself to figure something out. There’s a huge benefit to walking away from it or sleeping on it, and coming back to it with a fresh mind.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8o0jybcvr0wsej7yn9ts.png)

## Mastering the craft
As frustrating as they may be, facing bugs dead-on is always the best approach. You simply can’t learn to code without learning to debug.

This is why I’m really excited about the new course we’ve launched at Educative: [Mastering Debugging: Techniques for Efficient Code Diagnosis](https://www.educative.io/courses/mastering-debugging-techniques-for-eficient-code-diagnosis?utm_campaign=learn_to_code&utm_source=devto&utm_medium=text&utm_content=&utm_term=&eid=5082902844932096).

With this course, you can get hands-on with various types of bugs and debugging strategies, all in a controlled environment. Debugging can be intimidating, but in our AI-powered learning platform, you’ll be able to get feedback and guidance as you build your confidence with concrete debugging skills.

Happy learning!

– Fahim