Stand Out and Dare to Disagree

2012, Thursday afternoon, sprint review. Twelve smart engineers, three product people, zero decisions. Every proposal dissolved into “yeah, that could work, too.” We left the room with another action-less Jira ticket. That was the moment I realised: trying to keep everyone happy can freeze a team solid.

I’ve slipped into that behaviour myself (well, more than once) because short-term agreeableness does help with performance reviews. Long-term, though, it turns you into background noise. Teams outgrow you, products pass you by, and the only thing that sticks is the reputation for staying quiet.

The instinct to avoid friction is human. Computers are predictable; people aren’t. Add in remote chat threads where tone is a guessing game and it’s easy to default to neutrality. Sometimes that neutrality is even ethical — data governance meetings, for instance, where speaking up can expose sensitive strategy. But when neutrality becomes a reflex rather than a choice, it costs you originality.

✅ Quiet rooms feel safe. They rarely ship the interesting work.

So, yes, I’m arguing for being willing to polarise. Not for the thrill of the argument — the internet has enough flame wars — but because clear opinions backed by experience are how you signal value. Say you believe functional programming beats OOP for concurrency. Half the room may disagree; the other half now knows exactly when to call you.

That clarity only works if the opinion is anchored in evidence. Shouting nonsense doesn’t turn you into Steve Jobs; it turns you into an all-caps comment on Hacker News.

Update 16 May, after a thoughtful Reddit thread:

Polarisation is not a KPI. The point is to cultivate informed stances that naturally diverge from the mainstream. Good leaders don’t hunt controversy; they accumulate experience until disagreement is inevitable.

The goal, in other words, is productive tension — the kind that moves a roadmap forward, not the kind that burns people out.

You can absolutely succeed without ever stirring the pot, but the ceiling is lower. Here’s where lack of conviction bites:

1. Product scope balloons when you try to satisfy every persona. Features drift, teams fatigue, nobody loves the result.
2. Developers who never take a side stay in the “nice to have on the project” bucket. Specialists who say, “this database choice will hurt us in two years” end up leading architecture reviews.
3. Cultures without opinionated defaults feel inclusive at first, then stall. New hires spend weeks guessing what “good” looks like. (I’m not entirely sure this scales beyond small teams, but I’ve watched it stall a small to medium-sized organization.)

That said, some companies thrive on psychological safety and gentle consensus — think research labs where creativity needs room, or healthcare software where uptime matters more than ego. Collaboration can outperform conflict when the problem space rewards patience. Balance matters.

Greatness and controversy aren’t the same thing, but they rhyme. Linus Torvalds is famous for both code and colourful emails; database maintainers who quietly optimise Postgres extensions earn respect through depth rather than headlines. Either way, it’s the clarity of vision that sticks.

The upside of being specific is engagement. Kevin Kelly called it the “1,000 true fans” theory, and I still like the math. A thousand people who really care about what you do will fund a career, open doors, and argue on your behalf when you’re not in the room.

You won’t meet most of the eight-billion humans alive today. You only need the sliver whose worldview overlaps with yours. The easiest way to find them is to articulate that worldview, even if it repels others.

Example time. Vim and Emacs built tribes by being unapologetically opinionated. Then VS Code came along with a friendlier default, lowered friction, and swallowed market share without a single holy war. Both playbooks worked — one through sharp edges, one through inclusivity. The common thread is deliberate positioning, not bland “whatever you like” tooling.

Linux follows the same pattern: not for everyone, yet indispensable for those who crave control. Photoshop, Blender, Oracle — different domains, same story. Deep customisation builds loyalty even if the surrounding discourse stays polite.

So aim to be indispensable to a subset rather than tolerable to the crowd. Widen later if it makes strategic sense. (I could be wrong, but widening is easier than carving out focus after the fact.)

Dealing with criticism

Post anything vaguely strong online and you’ll attract both allies and drive-by snark. The skill is learning which is which.

Noise is disposable. It usually reads like: “This is stupid, you’re stupid, the world is stupid.” Useful feedback, on the other hand, repeats across sources and points at something you half-suspected might be weak.

✅ Some opinions age poorly. That’s a feature, not a bug. Let them.

Vim still can’t exit without a cheat sheet, yet it thrives. Why? Maintainers iterate without diluting the core. Same strategy works for personal viewpoints: adjust, don’t blur.

Make bold calls consciously. Accept that a portion of the room will roll their eyes. Over time you’ll spot the difference between bored hecklers and people raising real flags.

Quick loop for standing out:

1. State the thing you actually believe.
2. Listen for patterns in the pushback; refine accordingly.
3. Ignore pure outrage. Life’s short.
4. Thank the folks who share your wavelength — they’re rare.
5. Return to 1.

Disagreement isn’t a sport to win. It’s a tool to sharpen ideas. Choose your battles, but don’t default to silence. The field already has enough anonymous devs merging anonymous PRs.

I’ll keep saying JavaScript is my least favourite language until someone shows me a counter-example that changes my mind. Maybe that someone is you. Comments are open.

So, what do you think?

---

Other Newsletter Issues:

• Developer Mental Health
• Healthy Code Reviews
• 10x Engineers
• Software Development Estimations