The argument started, as so many do, over something genuinely trivial.
It was a Tuesday afternoon in a shared office above a sandwich shop in Portland, and my colleague Marcus had left a comment on my pull request that said, simply, "opening brace should be on the same line." I had put it on the next line. I had always put it on the next line. My fingers had been trained, over years of writing C-adjacent code, to drop the cursor, hit return, and then type the brace. It felt right. It felt, if I'm honest, correct in some deep aesthetic sense I couldn't fully articulate.
We went back and forth for forty minutes in the comments. Forty minutes. The feature itself — a small change to how we paginated search results — took maybe two hours to write. We spent a fifth of that time on a question that had exactly zero bearing on whether the code worked.
That was the moment I started to understand what code style arguments are actually about. And it took me a few more years to finish the thought.
The Feeling Beneath the Formatting
What Marcus and I were doing that Tuesday wasn't really about braces. We were negotiating something older and more human: the question of whose taste gets to define the shared space. Code, when you work on a team, is a commons. Everyone has to live in it. And when someone writes in a style that differs from yours, there's a low-grade friction — a sense that you're reading someone else's handwriting in a notebook you thought was yours.
I've come to think of code style preferences the way I think about accents. Your accent is the one that sounds neutral to you. Everyone else's sounds like a choice. But of course, yours is also a choice — it's just a choice you made so long ago, under such formative conditions, that it stopped feeling like one.
The brace-placement wars, the tabs-versus-spaces debates, the question of whether a line should be 80 characters or 100 or 120 — none of these have objectively correct answers. Studies have been run. Programmers have been surveyed. The results are, reliably, inconclusive. What is conclusive is that consistency within a codebase matters enormously, and that the specific convention chosen matters almost not at all.
This is the thing I had to learn: the fight is never really about the rule. It's about who gets to make the rules.
The Formatter That Ended the War
Sometime around 2018, I started working in a codebase that used Prettier. For the uninitiated, Prettier is an opinionated code formatter — it takes your code, ignores whatever style choices you made, and outputs something consistent according to its own fixed opinions. You don't configure it much. That's the point.
The first week, I hated it. Prettier kept reformatting things I'd written in ways that struck me as ugly. It would collapse my carefully spaced object literals into single lines, or break my single-line arrow functions across three lines, based on some internal calculation about line length. It felt like having an editor who rewrote your sentences without asking.
But here's what happened by week three: I stopped seeing the formatting at all.
That's the only way I know to describe it. The code looked consistent. Every file looked like every other file. And because there was nothing to argue about — Prettier had made all the choices, and those choices were final — my brain stopped spending cycles on the question. I could read the code. That was it. That was the whole job.
I've since talked to enough developers to know this experience is nearly universal. The transition from "I hate what this tool does to my code" to "I no longer think about formatting" takes somewhere between one and four weeks, depending on how entrenched your preferences were to begin with. After that, the formatter becomes invisible. What's left is the actual problem you were trying to solve.
There's a lesson in there about the cost of optionality. When you can argue about something, you will argue about it. Remove the option, and you remove the argument. The formatter isn't just saving keystrokes — it's saving the forty minutes Marcus and I spent on a Tuesday that we will never get back.
What Good Style Actually Protects
I want to be careful not to overcorrect here, because I've seen that mistake made too. The conclusion that "style doesn't matter" is wrong. It's just a different kind of wrong than "my style is correct."
What style actually protects is reading speed. The cognitive load of parsing unfamiliar patterns is real and measurable. When a codebase is inconsistent — when one module uses early returns and another uses deeply nested conditionals, when some files have JSDoc comments and others have none, when variable naming conventions shift from camelCase to snake_case depending on who wrote the file — the reader has to constantly recalibrate. It's the equivalent of reading a book where the font changes every chapter. You can do it. It's just slower and more tiring than it needs to be.
So style matters. Consistency matters. What doesn't matter is which specific style you pick, as long as you pick one and hold to it. This is a genuinely liberating idea once it sinks in, because it means you can stop defending your preferences as if they were principles. They're not principles. They're habits. Habits are negotiable.
The best engineering teams I've worked with have all shared a particular quality: they have strong opinions about process and weak opinions about taste. They care intensely about how decisions get made — who reviews what, how conflicts get resolved, what the formatter settings are — and they care very little about whether the formatter's output matches what any individual engineer would have written by hand.
The Thing I Still Haven't Fully Resolved
Here's where I have to be honest about the limit of my own conversion.
Automated formatters solve the small-scale style questions beautifully. Brace placement, indentation, line length — these are mechanical, and machines handle mechanical things well. But there's a larger category of style questions that no formatter touches, and those are still genuinely hard.
How long should a function be? When does a comment add clarity versus state the obvious? Should this logic live in a helper function or stay inline? Is this variable name expressive or verbose? These are questions of prose, really — the same questions a writing teacher asks of an essay. And they don't have automated answers, because they depend on context, on what the reader already knows, on what the code is trying to communicate and to whom.
I've made peace with the mechanical stuff. I haven't made peace with this layer, and I'm not sure I should. Some friction is productive. The argument about whether a function is doing too much, or whether a name is pulling its weight — that argument is often worth having, because it's an argument about what the code means, not just what it looks like.
Maybe that's the distinction I was groping toward, that Tuesday above the sandwich shop in Portland. Marcus and I were arguing about appearance when we should have been arguing about meaning. Or maybe we shouldn't have been arguing at all — maybe we should have just run the formatter and gone to lunch.
I still don't know how I learned to stop worrying about code style so much as I know that I did, eventually, stop. What replaced the worry wasn't indifference. It was something closer to proportion — a sense of which disagreements are worth the energy and which ones you should just let a machine settle for you.
The brace goes on the same line now. Prettier said so. I've made my peace with it.