Like most software engineers, I've spent most of my career reading other people's code. Between pull requests, tracking down bugs, building out new features, and just plain old research to learn a code base, there is a lot of time an engineer will sink into trying to understand what other people are thinking.

Hell, if you’re around long enough you’ve probably come across indecipherable code that a previous version of yourself wrote, and if you’re lucky you’ll have proof of your growth when you cringe at some of it.

All of this is to say that I’ve come up with a few questions I ask myself when I approach adding new and fixing old code. Things I find helps avoid the classic pitfalls of refactoring “bad” code and making it “clean”.

Is it messy, or is it complex?

Messy and complex are often conflated. It’s the primary impetus behind a lot of unnecessary rewrites — especially when written in a language or framework that you’re unfamiliar with. Particularly when said framework/language is not currently “cool”. No one likes having to learn new things to build a feature that they already know how to build. Besides, that old code is messy as heck! Lots of it is completely unnecessary. You could make this much cleaner and more efficient.

Sound familiar? Tell me, how much did your stomach drop when you happily deployed your new clean code and now support is inundated with bug reports? What do you mean people on old iPhones can’t load the page anymore? Huh, the layout is broken in Firefox? Why has our accessibility score dropped below an acceptable rating? You'll discover that most of that "messy" code was written to solve those same bug reports over the last few years. The code wasn't messy. It was battle-hardened.

Take those few extra cycles to understand the purpose of something. If you don't know why it's there, sure it could be left over from something long removed, but it also could be something you don't yet know you don't know. Getting better at recognising this comes down to experience, but at least being aware of it means you'll be less likely to remove something in future that you don't understand.

Do I actually have to rewrite this?

The second best thing a good software engineer does is write code. The best is to delete it. Every line of code added to a codebase contributes to headaches. That code must be tested, understood by others, maintained, and considered for future changes. It is also a potential area for bugs, regressions, security issues, etc. You should always attempt to reduce the amount of code you write in any way possible, and the best way to accomplish this is through code reuse.

It's easy to fall into the trap of writing new and clever code, but reusing existing code is always better. This is true both in terms of time spent and code quality. As mentioned above code isn't messy by default, but because it's been used and abused over time. You can write some new code that is clean and elegant but it won't cover all the edge cases and bugs that the messy code has already solved.

What's the simplest way I can write this code for future use?

If you absolutely must write new code make sure you're writing as little as possible and that it's as simple as you can make it. This doesn't mean being clever -- it means being clear. You always want to write code that is easy to read, understand, and maintain. Chances are you work in a team and might not always be there to show someone how the code works. You have to make it accessible to others, especially those without as much experience as yourself.

Is there something close to this functionality that I can modify to cover both use cases?

Recycling code is when you take existing code and modify it to include your use case without breaking the original purpose. This can be as simple as just a helper file within your codebase or something completely independent like a library (useful when separate services do similar things but comes with issues around maintenance and ownership). Which way you take this is up to your team or organisation to decide.

Regardless of how you intend to refactor a code base, I hope that you always go in with a few of these things in mind. Remember that no one wants to write bad or messy code. Everyone wants to do their best work but a lot of the time the reality of priorities and deadlines can mean decisions were made at that time that were considered good enough. Generally, the end user doesn't care about the difference between messy and clean code as long as the functionality is the same. Remember to practice patience and thoughtfulness, and to remain humble, because the next time you're cursing someone's bad code you might see your name in the git blame column.