Why Don’t I Do the Right Thing?

We all want to do the right thing.
But more often than we like to admit — we don’t.

As a software engineer with over 8 years of experience — 5 of which have been in large-scale, high-stakes systems — I’ve come to realize that knowing the right thing is only half the battle. The other half? Dealing with human limitations, organizational friction, and psychological barriers.

This post is an honest look into why we often don’t do what we know is right, and what that actually says about our industry, our teams, and ourselves.

🧠 How much decision-making power do we really have?

According to Self-Determination Theory, autonomy is a key factor in motivation. But in many real-world teams, decision-making is distributed unevenly — or worse, diffused to the point of paralysis.

I’ve often found myself knowing what needs to be done — refactor a service, modularize the frontend, replace a broken CI process — but not having the clear mandate to act on it.

You hesitate, you rationalize, and eventually… you postpone.
In a system with unclear ownership, “right” often becomes “later”.

🛠 Where are we in the software lifecycle?

You can’t treat a legacy system like a greenfield. And yet, many developers beat themselves up for not building “clean code” in a swamp of production bugs and feature pressure.

Context is king.

In early development, you have a chance to lay strong foundations. But in later stages — especially during scaling or firefighting — survival trumps architecture. That’s not failure. That’s lifecycle reality.

Instead of asking “Why didn’t we do it right?”, ask:
“Did we do what was realistic given our constraints?”

💸 Why we stick with bad tools (even when we know they’re bad)

This one hits close to home.

We’ve all used tools we knew weren’t great — maybe even regrettable.
So why do we keep using them?

1. The Cost of Inertia

Switching tools is rarely just about code. It’s about:

• Retraining the team
• Updating documentation
• Rewriting infrastructure
• Risking bugs during migration
• Losing velocity during onboarding

Even when better tools exist, momentum keeps the current tool alive. This is known as the “sunk cost fallacy” — the more we’ve invested in something, the harder it is to walk away.

2. Team Culture and Shared Illusions

Sometimes the team knows the tool sucks. But no one speaks up.
Why? Because everyone assumes everyone else is fine with it.

This is a classic case of pluralistic ignorance — a psychological phenomenon where everyone privately disagrees with a decision but publicly goes along with it because they think they’re the only one.

I’ve seen teams suffer through awful workflows for years… only to later admit they all hated it. The silence cost them years.

3. Fear of Regret

What if the new tool fails? What if the migration breaks prod?
Many engineers would rather live with a bad known than risk a worse unknown.

This fear makes us overly cautious — especially in high-stakes systems. But progress requires discomfort.

🧑‍💻 Sometimes, we just don’t have the people

In fast-paced environments, the bottleneck isn’t usually knowledge. It’s capacity.

You can have the best plan, the cleanest RFC, the strongest rationale — but if you only have 3 engineers maintaining a 10-person system, even the “right thing” becomes a luxury.

Leadership often wants velocity, not technical perfection. And it’s up to senior engineers to balance tech debt with delivery, without burning out or burning bridges.

🧩 What else gets in the way?

Here are some other invisible blockers I’ve seen over the years:

• Lack of psychological safety – You don’t challenge bad decisions because you don’t want to be seen as “negative”
• Short-term reward systems – You get praised for features, not for refactors or cleanup
• Too many cooks – Decision by committee leads to compromise, not clarity
• Bad estimations – Refactors always look longer than features, so they get cut
• Unclear ownership – No one feels responsible for long-term health

🚀 So… what now?

Doing the “right thing” in software is rarely simple.
It’s often a messy negotiation between:

• Business reality
• Human bandwidth
• Organizational inertia
• Team dynamics
• And your own energy levels

But here’s what has helped me over the years:

• Start small: Don’t wait for the “perfect time” to refactor — fix one thing per PR
• Make invisible work visible: Log time spent on improvements, track value delivered
• Talk openly: You’d be surprised how many teammates silently agree with you
• Document intent: Even if you can’t fix it now, explain what should happen later
• Mentor junior devs: Teach the why behind clean code — not just the how
• Lead by influence: You don’t need a title to nudge a team in the right direction

📚 Recommended Reading

If you’ve ever struggled with this, you’re not alone. These helped me a lot:

• Drive by Daniel Pink
• The Psychology of Computer Programming by Gerald Weinberg
• Software Engineering at Google by Titus Winters et al.
• Sunk Cost Fallacy (Wikipedia)
• Self-Determination Theory

At the end of the day, doing the right thing in tech is a leadership act, not just a coding decision.
And sometimes, leadership looks like slowing down — or even saying no.

Let’s keep striving, one small choice at a time.

– Ramin ✌️