Outgrow Your Taste, Don't Defend It

Central idea: Building a software solution is three separate activities: understanding a reality, engineering a general machine, and encoding the one into the other. Each answers to something outside you. Taste, which answers only to you, is required by none of them. It is the name we give the three before we have learned to tell them apart. Taste is for what cannot be argued; use it on work that can, and you are using it wrong.

Reading time: ~9 min

The word we reach for#

Ask why one piece of software is better than another, or one product, or one design, and the answer now is taste. The word has become the highest thing you can credit a maker with. It is the scarce sense that supposedly survives even when a machine can generate plausible work in seconds. And notice that it is an aesthetic word, borrowed from art and style. It is doing a job that is not aesthetic at all: deciding whether the thing someone built actually works for the people who need it. The serious advocates will say taste was never about aesthetics. Hold that. It is the most revealing thing they say, and I will come back to it.

I am not above this. I have trusted my taste for years and still catch myself at it. And by software I mean more than code. I mean the whole act of turning a messy problem into a working solution, made of parts that have little to do with one another. Pull them apart, and taste, the thing we were sure mattered most, turns out to be required by none of them.

The three things you are actually doing#

When you build software you are not doing one thing. You are doing three, and they differ in kind.

You are understanding a reality: how the business actually works, what the people you build for actually do, the exceptions and workarounds the official process hides. This is not software engineering. It is closer to fieldwork. You investigate it; you cannot intuit it from your chair. And you are not capturing the reality whole. You are only building a useful theory of the part that serves your goal. That orientation is what makes the work possible instead of hopeless: the goal tells you what you can safely ignore.

You are engineering a general machine: the domain-agnostic craft of making software hold up. Concurrency, error handling, module boundaries, the patterns that keep a system from collapsing under its own weight. This part is the same whether you build a CRM or a game, and it is mostly solved. We have the tools. The gap is rigor, not mystery.

And you are encoding the first into the second: expressing your understanding of the reality as the types, states, boundaries, and invariants the machine will run.

Three activities. One is not even software engineering. None is the same skill. And you do all three within the same hour, which is exactly where the trouble starts.

Watch taste fail to appear#

Go through the three and look for the place taste decides.

Each one answers to something outside you. Understanding answers to the reality: you are right or wrong about how the warehouse reconciles its stock, and the warehouse, not your sensibility, settles it. Engineering answers to consequences: it deadlocks or it does not, it leaks or it does not. Encoding answers to fidelity: the code says what the model means, or it lies. Taste is the one thing that answers only to you. It has no seat at any of the three tables.

So what is left for it? Only the ties that are otherwise even, the choices where nothing with consequences rides on the outcome. "Taste decides" and "it does not matter" turn out to be nearly the same sentence. It is not that taste is bad. It is that when you name the things you actually do, taste is not one of them.

So why does everyone reach for the word#

Because you do all three at once and feel them as one.

In a single afternoon you investigate the domain, decide how to model it, and encode it. The whole thing arrives as a single undifferentiated competence: a sense that this is right and that is wrong. The sense is real. But taste is just the name for the three activities before you have pulled them apart. It is the fog, not a fourth skill hiding underneath it. So outgrowing your taste is not about acquiring a rarer sensibility. It is decomposition: asking which of the three each feeling belongs to, until the taste has dissolved into the real thing it stood for.

The word slips, and it is a tooling gap#

Watch the word travel between roles, because that is where it goes wrong. It starts with the makers, the founders and designers whose work is mostly the first activity, understanding a reality. That activity has no immediate judge. A domain model is proven right or wrong by the world, slowly and through noise, never by a compiler in the next second. In their hands "taste" is a forgivable name for understanding that nothing has yet forced to decompose. Then it migrates. The engineer who only encodes, handed a finished model, picks the word up and uses it where a compiler, a test, and production all return a verdict now. Same word, opposite world. It has slid from the work with no immediate judge onto the work a machine checks. There it is only a way of not looking at the answer in front of you.

Neither instinct is more valid, though. The two worlds differ only in how well equipped they are. The engineer is ringed with judges and cannot hide for long. The maker lives where almost none exist yet. So the word is less a verdict than a debt: the instrumentation that would force the decomposition simply has not been built. That is a task, not an excuse. You can make an understanding of a domain far more explicit and testable than we bother to. You never fully arrive, because human reality answers slowly and no method makes the market as sharp as a compiler. But for the roles with the fewest tools, outgrowing your taste partly means building the tools that let you.

When taste seems to work#

Sometimes it really does seem to, and developer tooling is the clearest case. The person building the tool is the person who uses it. Maker and user share one life, one daily reality. So the first activity, understanding a reality, is already done, for free, before the work even starts. You do not investigate your user. You are your user. What looks like flawless taste is understanding you never had to pay for, because your own life handed it to you. Free, and so invisible, and so misnamed.

It is also why the makers of tools seem to share a single taste. Real taste never converges; that is half of what the word means. Theirs converges, because what they share is a condition, not a preference. The agreement among peers, which everyone reads as the proof of good taste, is the proof that it is not taste. It is a common reality wearing the mask of a common sensibility. And it holds exactly as long as the resemblance does. The day your users stop looking like you, the taste fails and you cannot see why, because you never knew it was understanding underneath. The place taste seems to work best is the place it was most certainly never taste.

Taste is borrowed, and it is the larval stage#

It helps to see where the feeling comes from. Mostly it is borrowed. The type checker that refused your sloppy union, the linter that flagged your dead branch: each is a named practice someone worked out and baked into a tool. Use good tools for years and you absorb the shape of those practices without ever reading their names. So when you "just sense" something is off, you are usually recognizing a pattern that already has a name, in a book you have not opened.

That is why taste is, at best, pre-learning. It is the pre-verbal stage of a skill: the intuition you have before the name, before the structure, before you can say why. I say this as someone who reached half his own ideas by instinct and only found their proper names while writing them down. The work is to keep converting, feeling into name, name into structure, structure into something you could defend to a person who disagrees. I am not finished. Nobody is.

Why ego moves in#

So if taste is borrowed, larval, and decisive only when nothing is at stake, why do capable people wrap their identity around it?

Because it is the one corner of the work where you cannot be proven wrong. You can be wrong about a domain, a boundary, an invariant, a model, and reality or production or the next engineer will eventually tell you. Taste is the only place that never will. There is no disputing a preference. Ego wants more than almost anything to be safe from error. So it does the rational thing. It flees the three accountable activities, where failure is public, and settles on the one hill where it can never be embarrassed. Heavy taste-talk is usually that. Not expertise, but the sound of someone staking their identity on the only thing in the craft that cannot be checked.

That gives the distinction worth keeping. The problem was never having taste. Everyone has it. The problem is taste that refuses to decompose, instinct frozen into a credential instead of resolved into one of the three real things. The failure is not a kind of person. It is the choice to stop pulling the fog apart.

What they are actually reaching for#

Here is the generous part, and the true one. People who reach for taste are reaching for something real. When a machine can produce infinite plausible code, some scarce human skill clearly separates the good from the slop. They feel it. They are right that it is there. They have just named it wrong.

Take their strongest case. It is not the shade of a button, but taste as repeatable judgment under uncertainty: seeing what is good before others can, and being proven right when they catch up. Hear what that admits. "Proven right when they catch up" means the judgment answers to a reality outside you, one that will confirm or refute it. The moment it does, it has stopped being taste and become understanding. The strong case for taste is understanding wearing the word, because the word sounds like a gift you were born with rather than work you went and did. What is left over, pure preference accountable to nothing, is exactly the part that breaks only the ties that do not matter. Push it as hard as you like and taste splits: where it is good it is understanding, where it is only taste it does not matter.

The difference, in the end, is the direction of the gaze. Taste looks in, at your own sensibility. Understanding looks out, at a world you have to go and find and build a working theory of. One is consulted, the other discovered. That is why no tool will ever hand it to you. Even the irreducible part, the tacit residue an expert cannot put into words, still points outward, at reality, in service of others. It is understanding that has not finished speaking, not preference dressed as authority.

A doorway, not a room#

None of this is reason to be ashamed of the feeling. It is where everyone starts, and the best engineers I know never lose it: a live, restless sense that something is wrong long before they can prove it. That intuition is precious. It is the start of every good decision they make.

But it is the start. It is a doorway, not a room you furnish and move into. Walking through it is small and repeatable. Treat every "this feels off" as a debt: find which of the three it belongs to, and make it explicit enough to defend or be corrected on, for the people who will never see your taste and never needed to. It is the discipline I keep arguing for on the code itself: do not leave the important things implicit, encode them. Here it is turned inward, on your own knowledge. Encode your taste; do not trust it. Defend it and you stop at the door. Decompose it, over and over, and you get to go inside.