Taste in Engineering

We talk about technical skill, but rarely about taste. What makes some engineers consistently make better decisions? An exploration of the aesthetic dimension of software engineering.

There is a quality I keep noticing in the engineers I most want to work with, and it is not raw skill. It is taste. The ability to look at three reasonable options and quietly know which one will still feel correct in two years.

Taste is hard to talk about because it sounds elitist. But pretending it does not exist makes us worse engineers, not more egalitarian ones.

What I mean by taste

Taste is not opinion. Opinion is "I prefer tabs." Taste is the accumulated judgment that lets you walk into an unfamiliar codebase and feel, within minutes, where the rot is and where the care is.

Some operational signals I watch for:

• The engineer who deletes more than they add in a refactor
• The one who pushes back on a "simple" feature because the data model is wrong
• The one whose pull requests have boring titles and quietly fix three latent bugs
• The one who, when asked for an estimate, asks a question instead

None of these are about cleverness. They are about knowing what matters.

Where taste comes from

I do not think taste is innate. I think it comes from three things, all of them slow.

Reading code you did not write

Most engineers write far more than they read. The ratio should probably be inverted. Reading codebases like the Next.js source, the Postgres internals, or any well maintained open source library teaches you what good looks like in a way that no tutorial can. You start to feel the difference between code that was thought about and code that was typed.

Living with your own decisions

Taste is mostly post-mortem. You do not develop it by making good decisions, you develop it by making decisions and then having to live in the building you made. Earlier in my career working on regulated systems, the architectures I had to maintain for three years taught me more than any I shipped and walked away from.

This is why senior engineers who hop projects every six months often have less taste than mid-level engineers who have stayed somewhere long enough to feel their own consequences.

A small set of strong examples

Almost everyone with strong taste has a few canonical references they return to. Specific systems, specific authors, specific code. Not a thousand. A handful, internalized. For me it is things like the Unix design philosophy, the React team's writing on tradeoffs, and a few quiet codebases I have worked in over the years.

How taste shows up in decisions

Taste is most visible at the moments where the right answer is not technically obvious.

Choosing what not to build. Most product specs are too big. The taste move is to find the smallest version that still solves the actual problem. From teams I have worked with, the engineers with taste are the ones who can say "we do not need this yet" without making it a fight.

Naming. The names you choose are a load bearing decision. A bad name compounds for years. A taste-driven engineer will sit with a name for an hour, and they are not wasting time.

Boundaries. Where one module ends and another begins is the highest leverage decision in a codebase. It is also the one most often made on autopilot. Taste here is the difference between a system you can extend in year three and one you cannot.

Boring choices. Taste, in my experience, almost always points toward boring technology. Postgres before a vector store. A monolith before microservices. Server rendered pages before a client framework. The boring answer is usually correct, and recognizing that takes more taste than chasing the new thing.

How to develop it on purpose

A few practices that have worked for me and people I have advised:

1. Keep a decisions journal. Write down the choice, the alternatives, and what you expected. Re-read it six months later. The gap between expectation and reality is where taste grows.
2. Read one strong codebase per quarter. Not skim. Actually read. Trace a feature end to end.
3. Pair with someone whose taste you trust. Not to be taught, but to watch what they notice. Half of taste is what you choose to look at.
4. Ship something you have to maintain. Side projects are the cheapest taste gym. They force you to live with your own decisions.

If you want to see how I think about this in client work, the insights section has more on it. And if you are weighing a real decision and want a second pair of eyes, /start-project is the door.

The uncomfortable part

Taste is unevenly distributed, and pretending otherwise leads to weak teams. But it is also developable, in a way that raw IQ is not. The good news is that almost any engineer who reads, ships, and stays put long enough will end up with more of it than they had a year ago. The work is the curriculum.

References

• Paul Graham: Taste for Makers
• Dan Abramov: The Wet Codebase
• John Ousterhout: A Philosophy of Software Design