30 September 2026

Builders, Preachers, and Talkers

Builders, Preachers, and Talkers

Spend enough time in the software industry and you start noticing a pattern.

There are people who build things.

There are people who teach people how things should be built.

And then there are people who mostly talk about the things the first two groups build and teach.

I call them Builders, Preachers, and Talkers.

These aren’t job titles. A person can move between these roles. Someone can be a Builder on Monday and a Preacher on Friday. And, of course, someone can occasionally be all three.

But if you spend enough time around software, you can usually tell which mode someone spends most of their time in.


The Builders

Builders start with a problem.

A customer has a problem.

A business has a problem.

A developer has a problem.

Or sometimes they simply have an idea they believe is worth trying.

And then they build.

The Builder’s world is full of constraints.

There isn’t enough time.

There isn’t enough money.

The requirements aren’t clear.

The database isn’t perfect.

The architecture isn’t perfect.

The team isn’t perfect.

The code isn’t perfect.

And the customer isn’t particularly interested in whether the system uses the most elegant architecture known to computer science.

They want the problem solved.

So Builders make compromises.

They might start with a monolith when everyone on the internet is talking about microservices.

They might choose a boring technology because the team already knows it.

They might ship something that isn’t beautifully abstracted.

They might accept some technical debt because getting the product into users’ hands is more important at that moment.

This doesn’t mean Builders don’t care about quality.

Quite the opposite.

They have to care about quality because they have to live with the consequences.

But they understand something that is easy to forget when discussing software architecture in the abstract:

Every engineering decision has a cost.

The question isn’t whether you can build the perfect system.

The question is whether building it is worth the cost.

Builders eventually discover another uncomfortable truth:

A working imperfect system is often more valuable than a perfect system that doesn’t exist.

They build, ship, observe, learn, and iterate.

And sometimes they make money.


The Preachers

Then there are the Preachers.

Preachers spend their time thinking about how software should be built.

They study patterns.

They study architectures.

They write books.

They publish articles.

They give conference talks.

They create frameworks, methodologies, diagrams, checklists and principles.

And many of them are genuinely excellent at what they do.

A good Preacher can look at a problem and explain things that a Builder may not have considered.

They can say:

“Your boundaries aren’t clear.”

“Your abstraction is leaking.”

“You need better automated tests.”

“This coupling will hurt you later.”

“Your architecture doesn’t scale.”

“Your deployment process is fragile.”

And very often, they’re right.

The problem isn’t that what they say is wrong.

The problem is that reality has a budget.

The Builder may know that introducing another layer would make the architecture cleaner.

But it might also take three weeks.

The Builder may know that rewriting the system would eliminate technical debt.

But the business needs the feature next Tuesday.

The Builder may know that the theoretically ideal architecture would make future evolution easier.

But there are three developers, twelve customers and a runway that isn’t infinite.

The Preacher describes the ideal.

The Builder negotiates with reality.

Neither is necessarily wrong.

They are solving different problems.

And we need both.

Without Preachers, the industry can become a collection of hacks that nobody has thought deeply about.

Without Builders, we get beautiful architecture diagrams and conference slides without software that users actually depend on.


And Then There Are the Talkers

And then we have the Talkers.

Talkers don’t necessarily build the product.

They don’t necessarily write the book.

They don’t necessarily give the conference talk.

They don’t necessarily maintain the open-source project.

They mostly talk about the people who do.

Someone publishes an article.

The Talker finds something wrong with it.

Someone releases a product.

The Talker explains why it will fail.

Someone gives a conference talk.

The Talker posts a thread about everything the speaker got wrong.

Someone chooses technology A instead of technology B.

The Talker explains why anyone competent would obviously choose B.

Someone makes a pragmatic engineering compromise.

The Talker declares that the person doesn’t understand software engineering.

And social media gives Talkers an extraordinary platform.

A Builder might spend six months building something.

A Preacher might spend six months researching and writing something.

A Talker can spend six minutes commenting on both.

And sometimes that six-minute comment gets more engagement than the six months of work.

That can create a strange illusion.

The Talker appears influential.

They have followers.

They have opinions.

They get likes.

They participate in every conversation.

They always have something to say.

But attention is not the same thing as impact.


The strange power of not caring

There is something particularly interesting about the relationship between these three groups.

Talkers often believe that Builders and Preachers are paying attention to them.

Usually, they aren’t.

The Builder is busy solving the next problem.

The Preacher is busy writing the next book, preparing the next talk, researching the next idea, or helping the next group of developers.

Meanwhile, the Talker is writing a 27-post thread explaining why both of them are wrong.

And the Builder may never see it.

Even if they do, they may spend ten seconds reading it and move on.

Not because the Talker’s criticism is necessarily incorrect.

Simply because the Talker isn’t relevant to the Builder’s immediate objective.

That distinction matters.

You can win an argument on the internet and still change absolutely nothing.

You can get hundreds of likes for criticizing someone’s work and still have very little influence over what they actually do.

You can become very good at discussing the work of others without ever having to bear the consequences of making those decisions yourself.

That is the great advantage of being a Talker.

And also its great limitation.


The asymmetry

Builders and Preachers are exposed to reality.

Builders eventually find out whether their product works.

Preachers eventually find out whether their ideas help people.

Talkers don’t have the same feedback loop.

If a Builder makes a bad architectural decision, production will tell them.

If a Preacher publishes terrible advice, developers may stop reading their work.

But a Talker can be wrong every day and still continue talking.

There is almost no cost to being confidently wrong when your primary contribution is commentary.

That is why Talkers can be so loud.

There is very little friction between having an opinion and publishing it.


But Talkers aren’t completely useless

There is an important caveat.

Not every critic is a Talker.

Criticism can be incredibly valuable.

A thoughtful reviewer can prevent a Builder from making an expensive mistake.

A reader can identify a flaw in a Preacher’s argument.

An engineer can challenge an assumption that everyone else has accepted.

That’s not Talker behavior.

The difference isn’t whether you criticize.

The difference is whether criticism is connected to meaningful contribution.

A person who says:

“This approach has a problem. Here’s the evidence, here’s why it matters, and here’s an alternative.”

is contributing.

A person who repeatedly says:

“This is terrible. Anyone who knows what they’re doing would never do this.”

is mostly performing.

One creates signal.

The other creates noise.


Build. Teach. Or just keep talking.

There is nothing inherently wrong with talking.

We all do it.

We complain.

We argue.

We react.

We spend too much time explaining why somebody else’s approach is wrong.

But there is a fundamental difference between creating something and creating noise around what other people create.

Builders have something to show for their time.

They build products.

They solve problems.

They create businesses.

They employ people.

They serve customers.

And sometimes, they make a fortune doing it.

Preachers have something to show for their time too.

They write books.

They publish ideas.

They teach thousands of people.

They create frameworks and methodologies.

They influence how an entire generation of developers thinks about software.

And they too can build careers and fortunes around the knowledge they create and share.

Talkers can certainly create buzz.

They can generate engagement.

They can get followers.

They can spend their entire day reacting to whatever someone else has built, written, released or said.

But after all the posts, replies, quote-posts, arguments and hot takes, a simple question remains:

What did you actually create?

What did you build?

What did you teach?

What did you publish?

What did you solve?

What did you contribute that will still exist after the social-media conversation disappears?

Often, the answer is very little.

And that’s the important asymmetry.

Builders and Preachers are busy creating things that exist in the real world.

Talkers are often busy creating noise around them.

The Talker may be louder.

The Talker may get more likes that day.

The Talker may even convince themselves that they are having an impact because thousands of people saw their post.

But Builders and Preachers generally don’t need to win those arguments.

They already have something better:

something to show for their time.

A product.

A company.

A book.

An idea.

A community.

A body of knowledge.

A career.

A fortune.

Something that exists because they spent their time creating it.

So let the Talkers talk.

Let them criticize.

Let them judge.

Let them create another thread explaining why everyone else is doing it wrong.

Unless their criticism contains something genuinely useful, Builders and Preachers have very little reason to care.

Because while the Talkers are busy discussing them…

The Builders are building.

The Preachers are teaching.

And neither needs permission from the Talkers to keep going.

Kudos to the Builders and Preachers

So, kudos to all the Builders and Preachers who continue creating, teaching, sharing, and contributing to the community despite the constant noise around them.

Keep building products. Keep solving problems. Keep writing books. Keep sharing knowledge. Keep helping the next generation of developers.

There will always be people judging, criticizing, trolling, and telling you how you should have done it.

Let them talk.

Your work doesn’t become less valuable because someone posted a criticism about it.

At the end of the day, you have something to show for your time.

A product. A book. An idea. A business. A lesson. A community. A contribution.

That’s what matters.

Kudos to the Builders. Kudos to the Preachers.

And to the Talkers…

keep talking. The Builders and Preachers have work to do.