Less Dogma, More Rigor

AS A REWARD FOR READING TODAY'S POST, I'VE INCLUDED A LITTLE SURPRISE AT THE BOTTOM. Thank you for being a fellow Adventurer!

If there's anything we love in tech, a good argument seems to be at the top of the list.

Tabs or spaces? Vim or Emacs? React or Svelte (or Vue or Angular or geez why are there so many JS frameworks...😳)? “Real” APIs or RESTful ones? Grok, Claude, ChatGPT, or Llama... some of y'all reading this are already triggered, aren't ya? "BUT IT'S BECAUSE $my_choice REALLY IS BETTER AND HERE'S MY 147-SLIDE PRESENTATION TO TELL YOU WHY..."

We’ll spend hours passionately defending a tool, a language, even a design pattern... as if the very soul of software engineering depends on it.

These things we argue about aren't about impact... they're about identity.

We hold onto our preferences like they’re principles. We dig into positions long after the context has changed. We confuse conviction with clarity. And in the process, we slow our teams down, gatekeep unintentionally, and lose sight of the thing we’re actually here to do: solve problems well.

This isn’t a call to stop caring. It’s a call to care more about the right things.

Less dogma. More rigor.

Why Dogma Feels So Good

Dogma gives us certainty. And in software, certainty is in short supply.

The tech landscape is constantly shifting. New frameworks land every week. Best practices evolve. What felt cutting-edge last year is now “legacy.” In the middle of that chaos, strong opinions feel like stability. When we say "I only use X," or "Y is trash," we're carving out a sense of control. It's a pillar we can hang onto as we're buffeted by the latest round of hype.

But it becomes problematic when we adopt these things into our identity.

Developers, like all humans, are tribal. We rally around tools and philosophies like sports teams. “I’m a Rust dev.” “I don’t touch frontend.” “I only deploy with Terraform.” It feels good to be part of a tribe — especially one with strong opinions (and really dank memes 🤣).

And once we’re in a tribe? We protect it. We dismiss other tools reflexively. We repeat slogans (“Java is dead!”) without checking if they’re still true. We build personal credibility on top of technical choices that maybe just... worked for us once.

There’s nothing inherently wrong with strong preferences. They’re human. But when we treat them as universal truths, we start making worse decisions: for ourselves AND for our teams.

When Righteousness Becomes Rigidity

Strong opinions are only a problem when they become rules — especially when those rules are handed down without context.

Let’s talk about platform teams.

Imagine a platform team rolling out a sweeping set of “standards” to unify tooling across their company. The intent is solid: reduce complexity, improve onboarding, and create a common developer experience. The chosen stack? Docker, Terraform, GitHub Actions, and Go for backend services. All great tools. Architects salivate at the idea of a "clean" stack.

But there was a catch: these weren’t recommendations. They were requirements.

It didn’t matter if your team was maintaining a simple Python script. Didn’t matter if your service didn’t need infrastructure-as-code. Didn’t matter if you were new to Go and had zero internal support. You were expected to adopt the “golden path”.

At first, this looks like progress. The platform team can point to adoption charts and dashboards showing standardization. But out in the product teams, something else is happening:

Delivery slows. Teams spend weeks learning tools that didn’t solve problems they actually have.

Shadow systems emerge. Engineers quietly keep using older tools “just to get things done.”

Morale dips. Developers start referring to the platform as “the ivory tower.”

The standards weren’t wrong. The problem was the dogmatic approach to implementing them: The belief that there was one true way, and that every team regardless of needs or constraints must follow it.

Rigor would have looked different. It would’ve asked: What are we actually trying to enable? What tradeoffs are we willing to make? Where does consistency help, and where does it hurt?

Instead, the platform team optimized for compliance over collaboration. And in the end, they got neither.

Principles Over Preferences

There’s nothing wrong with having preferences. The problem is when we stop at preferences and never graduate to principles.

A preference says:
“I like using X because it’s familiar.”

A principle asks:
“What are we optimizing for?”

When we choose tools, frameworks, or patterns without aligning them to principles — like simplicity, maintainability, or developer autonomy — we risk making decisions that feel good in the moment but age poorly in production.

Let’s return to the platform team story.

The problem wasn’t that they picked Docker or Go. The problem was they enforced preferences as if they were principles, and skipped the harder conversation: what constraints are we actually trying to solve for? Imagine instead if the team had said:

“We want fast onboarding — so our tools should be easy to learn.”

“We want consistent deployments — so we need one reliable CI/CD path, but leave language choice open.”

“We want to support experimentation — so the platform should stay out of the way unless there’s a good reason not to.”

Those are principles. You can debate them, adapt them, and evolve them over time.

Tools are temporary. Contexts change. But principles, when they’re clear and grounded in team needs, can guide decisions even when everything else is moving.

If we want to be rigorous, we need to shift the conversation from “What does this tool let us do?” to “What are we trying to accomplish — and what tradeoffs are we willing to make to get there?”

Leading With Humility

The higher up you go, the easier it is to confuse influence with authority... and authority with correctness.

If you’re a staff+ engineer, a tech lead, or the person people look to when a hard decision needs to be made, your preferences carry weight. Whether you mean to or not, the tools you use (or dismiss) shape the culture around you.

This is where curiosity becomes more powerful than control.

Instead of:

“We always use X for this.”

Try:

“What problem are you solving, and what tradeoffs did you consider?”

Instead of:

“We should just standardize on Y.”

Try:

“Where does consistency help us? And where might it slow us down?”

The goal isn’t to avoid decisions. It's to make space for rigor! Your goal should be to create conditions where people feel safe to disagree, experiment, and explain their thinking. Dogma shuts that down... Curiosity invites it in.

And if you’re building internal platforms or setting standards for others, remember: the more control you exert, the more humility you need. Because the cost of being wrong isn’t just your own productivity; it’s multiplied across every team who follows your lead.

The best leaders I’ve worked with had strong opinions, and changed them often. They set direction, but held it loosely. They modeled how to prioritize outcomes over orthodoxy.

Because in the end, teams don’t succeed because they picked the perfect stack. They succeed because they made clear decisions, stayed aligned on the problem, and moved together.

Wrapping Up

Strong opinions aren’t the problem. It’s when we mistake our preferences for principles. When we trade curiosity for control. That's when things start to break.

If we want healthier teams, faster delivery, and better decision-making, we need to let go of the righteousness that makes us feel smart and lean into the rigor that helps us build well.

Because at the end of the day…

It’s not that tabs or spaces don’t matter — it’s that they don’t matter as much as we act like they do.

Side Note: The Adventures Continue Soon!

Next week, it's time for the launch of...

I hope you'll join me for Season 4 as we go on a DevEx Deep Dive... we'll learn how to start making improvements to the Developer Experience in our coding projects!

Come by and subscribe to The Adventures of Blink on YouTube so you won't miss out!