We all try to create good and clean code, projects that are maintainable and easy to change and yet, we don’t appreciate when we have one.
Do you remember the last time you easily change something in your code?
Maybe it was a simple constant that was only in one place, or a new parameter in an API endpoint that was fast to test. You might remember but I bet you didn’t stop to appreciate how easy the change was, how productive it felt and how it could have been much worse in other scenarios, it just felt right. You didn’t think too much about it because good code is invisible.
We don’t think too much about existing code until it gets in our way to accomplish what we want, in the same way we don’t appreciate our own good health until we get ill.
Product’s perspective
From the stakeholders of a product, good and maintainable code is expected, although rare to find.
They treat code in the same way that I treat my car. When I get into my car and start the engine, I expect it to work well and get me safely to my destination. I’d not be very happy if I see a warning light complaining about something I didn’t know it existed and I’d be even more concerned if three of them are on in the same trip.
When you work with product stakeholders, they don’t pay attention to the code. They don’t care about how many returns or lines you have in a single method or whether you use TDD or modify the code in production with an FTP client.
They see the project as the final user is going to perceive it. They’re trying to get the project somewhere else and code can help or prevent that from happening. They care about results in the form of features, bugs or speed, things way more tangible that the code you see in the editor.
The fact that your code is good and maintainable is a competitive advantage that only you and your colleagues truly appreciate and, although it affects all the stakeholders of the product in a big way, they’re just usually not aware of it.
And with all of this, if it’s very likely that few people notice how easy is to work with that project, why should you care?
This is your life
First of all, because, as Dave Thomas and Andrew Hunt mention in “The Pragmatic Programmer”: “this is your life”. Do you want to have a fulfilling pride of your accomplishments every week? Do you want to look at that piece of code and easily see how you made it better? Or do you prefer to spend the rest of your days in that company or project barely surviving, sweeping dirty code under the carpet with the hope that it’ll get better magically someday because you’ll have time for the ultimate refactoring (or rewriting the whole thing)?
Common goals
Outside your personal feelings and goals, you’re working in that project because, deep down, you care about something. It could be the mission of the company, your team, the users or even just the money you’re making there. In any case, the better the project is because you cared about your work, the more chances it’ll have to succeed. And even if it doesn’t, you won’t have any regrets that it was your fault.
Bad code is like a disease
Bad code can hurt and eventually kill companies. If your company can’t adapt fast enough in a new market others will pass by and win. If your users aren’t happy about the quality of something you’ve built and you don’t know where the issue is because the code is a mess, you might lose them. If they leave others might follow and soon, what you cared about when you started in that project, might be lost forever.
Do what you can every day to stay healthy and treat your code in the same way, you won’t regret it.