The unsexy truth
Nobody puts "wrote an ESLint config" on a highlight reel. There are no LinkedIn posts that go viral about standardizing folder structure. And yet, the teams I've watched ship the fastest are the ones that had The Argument About Trailing Commas exactly once and then never had it again.
Standardization is, at its core, a love language. It's how engineers say "I care enough about your time that I'm going to make this boring on purpose."
What standardization actually buys you
It's tempting to frame this as a tooling story — Prettier this, ESLint that — but the real wins are human:
- Faster code reviews. When the formatter handles 80% of the bikeshed, reviewers can focus on the actual logic. PRs go from "let's debate spacing" to "let's ship it."
- Easier onboarding. New engineers don't have to learn five flavors of the same pattern across the codebase. The first week stops feeling like an archaeological dig.
- Refactors that actually finish. Consistent code is mechanically
transformable code.
grep, codemods, and AST tools all become wildly more powerful when the team agrees on shape. - Less cognitive overhead. Every "how do we do X here?" decision saved is brainpower freed up for the things that genuinely matter.
Good architecture is like a good joke — if you have to explain it, it's probably not that great.
The pushback (and how to handle it)
Someone on your team is going to say "this stifles creativity." They are, politely, wrong — but in a way worth taking seriously. Creativity belongs in what you build, not in where you put the closing brace. Standardization isn't about making everyone identical; it's about deleting the meaningless choices so the meaningful ones get more attention.
The other common objection is "but the old code doesn't follow this." Great. That's fine. The new rule applies going forward. You don't need to boil the ocean to start making it warmer.
Where to start (a small, doable plan)
- Pick one repo. Just one. Don't try to standardize the org on day one.
- Adopt a single formatter. Prettier with defaults is fine. Don't overthink it. The win is consistency, not the config.
- Write down three patterns your team already agrees on. Make the invisible visible. Put them in a CONTRIBUTING.md and link it from the README.
- Add one lint rule per sprint. Slow is smooth, smooth is fast.
- Celebrate the diffs. When a 400-line "format the world" PR lands, throw it a little party. Boring infrastructure deserves applause too.
The closing thought
Standards aren't a cage. They're scaffolding. They're the thing that lets a team of ten move like a team of three, and they're how you tell future-you "I was thinking about you when I wrote this."
Be kind to future-you. Standardize the boring stuff.