Bad Code is your friend

What if I told you that there are unlimited (almost) opportunities to help you write better code? And can be accessed anytime you work on a legacy (or not) codebase. And on top of all this, they are free!?

Is there a resource like that??

Well, yes, and that resource is what I call "bad code"!

Bad code to the rescue!

Nowadays, it is very easy to get lost in the plethora of articles about new and, admittedly, exciting technologies. We get overwhelmed by the current trends. The resources to help us write better code are obscured by all that other (often useful) noise.

Even more, the appropriate experience that enables you to write better code seems harder to find. Most companies don't care about writing better code, and developers are left to work in lousy legacy code most times than not.

There is some good news, though. Bad code can be used as a knowledge treasure of things that were not implemented the right way. You can be mindful when you work on it and learn a ton. You can experience what went wrong and gain invaluable experience in improving it next time.

Stay with me, and I will provide some examples.

Good code can be objective; bad code is not

Before we learn how to use bad code as a learning resource, we need to talk about good code...

What is good code, though, is not a definition set in stone. Writing better code can mean many things, depending on who you ask. For a project manager, better code can be fast-written, without bugs, and feature-rich.

For a developer, though, it can be something very different. We love technology, and we enjoy playing around with it. Better code for some developers is code that is easily understood and follows best practices, and for others is code that is built using all the shiny new syntax available out there.

On the other hand, bad code is simpler to agree on. In a ball-of-mud codebase, the developers suffer working on and making changes, and the managers see deadlines pushed back and bugs introduced regularly.

Although initially detected by the developers, poor-quality code usually and gradually affects everyone.

How to use bad code

As I said earlier, I believe bad code can be helpful for anyone. I am a big believer in getting the most out of every situation, and with the right attitude, working on poor-quality systems can be a great teacher.

My suggestion is simple, bring presence to your mind when you touch that old codebase that resembles the photo below. Identify all the things that cause you mental strain. Is it hard to read the code? Do you need to search in multiple files to apply a change? Is the code very unpredictable?

Only do the fix by thinking about what brought the code to this situation in the first place. Don't be afraid to judge what you see. Have an opinion about the wrong things done there and even share it with someone. You will slowly see that these learnings will guide you to writing better code.

Examples

Identify bad code traits

Usually, it is effortless to identify a piece of bad code when you are called to work on it. In every step you make, you recognize the level of friction increasing and blocking you from achieving your goal. I have worked and written a fair amount of bad code, and spotting the problems is very easy. We will focus on a short list of two traits for our examples.

The first clue for me is the difficulty of understanding what the code does. Non-descriptive/insufficient naming or long functions can add many points to the difficulty system. Re-reading each function multiple times becomes the only tool to understand what is going on. So the first entry in the list of bad traits is hard-to-understand code.

After managing to modify the code, you check the results. The code behaves unpredictably all of a sudden. A function that seemed unrelated is not working anymore. The code is so interconnected that you can't predict the outcome. Not having test coverage is also adding to that effect. The more you try to understand, the more you find yourself lost in re-reading the same parts and moving away from your destination. Hard to modify code is on the list!

What did we learn from the examples above?

After a dreadful experience like the one mentioned above, we are convinced that we have to do a better job when we write our code.

We need our code to be a better experience than the one offered by the ball-of-mud code. You know that now because you had the "blessing" to work on something that was not done properly.

Furthermore, you have two new tools in your arsenal. You know that bad code has bad variable names and long functions that are hard to read. So good code is the opposite. Small cohesive functions and proper naming - two new tools to use.

We also saw that the code was interconnected and was hard to predict. You need your code to be more modular and easier to modify. Different functions are responsible for different things and are not repeated everywhere. Don't repeat yourself and protect the boundaries of your functions - another two new tools to use.

We know firsthand what to avoid and even how by just checking the bad code a bit deeper than usual. It will not be so easy, of course, but slowly you will be able to identify and learn better and more.

So next time you code in a nasty piece of code, enjoy the ride in the tressure land!