“It Works” Is a Trap

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.