How to get better at fixing broken code

On Friday, I wrote that the major differences between junior and senior developers is their ability to fix broken code.

Honestly, the only difference between a junior and senior developer is that you get better at identifying all the places where your code goes to shit.

There’s a bit more to it than that, of course, and we’ll talk more about that tomorrow.

But how do you get better at figuring out why your code isn’t working, and how to fix it? And how do you avoid common pitfalls in the first place?

I watch a lot of Bob Ross. One of the things he repeats often throughout the 31 seasons of his show The Joy of Painting is that, “if there’s any secret to this, it’s practice.”

That’s true of coding, too.

There’s no magic knowledge senior developers have that juniors don’t. They’ve just racked up a bit more experience and learned from making lots of mistakes.

The best way to get better at fixing broken code is to break a lot of code and then fix it. Work on lots of projects. Try lots of things. And when you get stuck, spend the time trying to figure out what’s wrong and how to fix it.

It’s a really painful process at first. Then it gets easier.

Eventually, you develop a bit of a sixth sense about what might be wrong. You’ll start to see stuff come up that you’ve encountered before, or that’s a lot like stuff you’ve encountered before, and have a good idea of where to start.

And every now and then, you’ll spend two hours trying to debug an issue caused by a simple typo that your eye keeps glazing over.

If you’re looking for some fun projects to work on, I have a free collection of 15 projects—with lessons, starter templates, and solution walk throughs—available at VanillaJSProjects.com.