You probably don't need to refactor that code
A work of art is never finished, only abandoned.
—Leonardo da Vinci
I used to work at a company where I’d say and hear this a lot:
“Ugh, this code is so bad, we should refactor it some time.”
Then we went on to add features to the same code without refactoring it for another three months.
All these little pieces of dirty code went on my perfectionist nerves, making me feel obliged to improve them.
But it was never a priority, and we always ended up having other work to do.
Every time I wanted to refactor our codebase, I got the same response from my tech lead: “It’s nice to have cleaner code, but it’s more important to have features that made our product more valuable and as a result more profitable.”
To me it seemed like a wrong philosophy for the engineering team, but the company kept growing and we kept building more and earning more.
I didn’t fully understand it at the time, but there was a lesson to be learned much later.
I was fed up with all social media platforms adding infinitely scrollable feed in their apps.
All of my sources of entertainment and news where becoming addictive drugs.
So I put together my favorite blogger’s websites and newsletters and built a blog post dispenser called BlogFrog. It took my one day to build the first version.
It wasn’t pretty, but it worked.
The source code was even less pretty, lots and lots of copypasta and duplicate code.
Next weekend, the ugly code went on my perfectionist’s nerve again.
But this time I didn’t have a tech lead, or an employer who paid me to work on BlogFrog, and I was the only user, so I started refactoring.
The first few hours I changed my code so that it was easy enough to add a new blog to the directory, and then it hit me…
The code was still ugly, but I didn’t have a good reason to continue refactoring.
I would probably have to spend another day cleaning it up, making it look like a code I was proud of, but the final product would have looked the same, what I (the user) saw was the same.
Having a personal project and using it myself helped me see the bigger picture.
I realized what my tech lead meant at the time: the code is not the product.
Refactoring is a never-ending process.
You don’t have to apply all design patterns and best practices you know in your code.
Your design and implementation doesn’t have to be 100% perfect.
A good rule of thumb I use is if my code is readable in my absence, and it is not that hard to add features to this code, it is most probably good enough.
It’s similar to editing your writings.
You can always make it better.
But at some point you should decide it is good enough.
That’s where you stop editing and move on.
But refactoring code is not editing your writings.
Because the code is not the final product.
Don’t refactor the code just for the sake of the code.