The Problem with "Let's Be Pragmatic"

The “lone programmer” is a myth.

Over the years, I've noticed something interesting.

Whenever someone suggests improving a process, changing the way a team works, or challenging the status quo, someone inevitably says:

Let's be pragmatic.

The more I hear that phrase, the more I wonder whether we're all talking about the same thing.

Because, in many organizations, pragmatism has become a convenient shield. It's no longer about finding practical solutions; it's about protecting the current way of doing things. It's used to justify why something shouldn't change rather than to explore whether it could be better.

Ironically, that's probably the least pragmatic approach of all.

What Does It Really Mean to Be Pragmatic?

One of the books that has influenced my career the most is The Pragmatic Programmer by Andrew Hunt and David Thomas.

Despite its title, the book isn't really about programming. It's about attitude.

If you look at the principles the authors propose, none of them encourage complacency. Quite the opposite.

They encourage curiosity.

They encourage learning.

They encourage questioning assumptions.

They encourage becoming an agent of change.

One of my favourite ideas from the book is simple:

Provide options, not excuses.

Whenever something cannot be done, don't stop at "it can't be done." Explain why, explore alternatives, and look for different paths forward.

Another principle encourages developers to become change agents. You can't force people to change, but you can help them understand why change might be valuable and invite them to participate in building something better.

None of that sounds like protecting the status quo.

Pragmatism Isn't About Preserving the Present

The philosophical definition of pragmatism isn't particularly complicated either.

Pragmatism judges ideas by their consequences.

If an idea produces better results, it deserves consideration.

If experience proves a better way exists, pragmatism doesn't ask us to defend the old approach. It asks us to adopt the new one.

Ideas are provisional.

Knowledge evolves.

Experience changes our understanding.

That's why I've always found it curious when someone invokes pragmatism as a reason not to improve.

Refusing to question today's solution simply because it works is not pragmatism.

It's comfort.

Continuous Improvement Requires Curiosity

This idea also connects naturally with Kaizen.

Many people associate Kaizen with manufacturing or organizational improvement, but its original philosophy is deeply personal. It encourages individuals to continuously evaluate their own work, reflect on what could be improved, and make small, incremental changes over time.

Improvement isn't a project.

It's a habit.

That habit requires something many organizations unintentionally discourage:

Curiosity.

Curiosity to ask whether there's a better way.

Curiosity to challenge assumptions.

Curiosity to learn something new, even when today's solution appears to work.

Software Is a Human Activity

Software development makes this especially obvious.

Despite the stereotype of the lone programmer, software has never been an individual activity.

Great software isn't built by isolated individuals protecting their own ideas. It's built by people discussing, disagreeing, learning from each other, and constantly adapting as new information becomes available.

Communication is as important as technical ability.

Learning is as important as experience.

Being willing to change your mind is often more valuable than being right.

So... Are We Really Being Pragmatic?

Perhaps the next time someone says, "Let's be pragmatic," we should pause for a moment and ask what they really mean.

Do they mean:

Let's find the simplest solution that works.

Or do they actually mean:

Let's avoid changing because what we have is familiar.

Those are two very different conversations.

Real pragmatism isn't about defending today's solution.

It's about finding tomorrow's better one.

The best teams I've worked with weren't idealists, and they certainly weren't stubborn pragmatists.

They were curious.

They questioned.

They experimented.

And they understood that the most practical decision isn't always to keep doing what already works.

Sometimes, the most pragmatic thing you can do is change.