I’ve started to distrust the phrase “it works.”
Not because it’s wrong—but because it usually hides a future problem.
Most bugs I deal with aren’t from things that were broken. They come from code that worked fine… until someone had to change it.
A quick example:
function processUser(user) {
if (user.type === "admin") {
sendEmail(user.email);
logActivity(user.id);
} else if (user.type === "guest") {
if (user.email) sendEmail(user.email);
}
}
Nothing wrong here. You ship it.
Then a month later:
- new user types show up
- email rules change
- logging becomes conditional
Now this “simple” function is where changes go to die.
What I’ve learned (the hard way):
- Every extra condition feels cheap at the time
- But it increases the cost of the next change
- And the next one
- And the next one
Eventually, nobody wants to touch it.
These days I try to optimize for changeability, not just correctness.
Not overengineering—just small habits:
- clearer names
- fewer responsibilities per function
- making dependencies obvious
Nothing fancy. Just less “clever.”
Because in real projects, the goal isn’t writing code that works once.
It’s writing code that keeps working when everything around it changes.
Top comments (5)
his is such a powerful reflection on the hidden costs of writing "working" code without considering its long-term maintainability. The phrase "It works" is often a trap because, as you've pointed out, what works today can quickly become a nightmare to modify as requirements evolve. Your focus on optimizing for changeability rather than just correctness is spot on—writing code that remains flexible and easy to change as new features or requirements arise is far more valuable in the long run. The small, mindful habits you mention—like using clearer names and reducing function responsibilities—are incredibly effective and often overlooked. This is the kind of wisdom that can help developers create more sustainable, future-proof systems. Beautifully said!
Interesting.
Great post
Interesting!
Good.