What Do Engineers Mean When We Say "Taste"?

Dancing with Robots: A Software Architect's Journey

SubscribeSign in

What Do Engineers Mean When We Say "Taste"?<br>Toward a decomposition of the least-examined concept in software engineering

Dave Griffith<br>Feb 25, 2026

22

Share

In 2004, I was building out the intentions and inspections system for IntelliJ IDEA in collaboration with JetBrains. If you’ve used any JetBrains IDE in the last twenty years, you’ve encountered this feature — it’s the thing that notices you wrote something subtly wrong and offers to fix it. When I started, the team thought there would be a couple dozen inspections overall. By the time I finished, there were hundreds, and each one required making at least a half-dozen judgment calls: what developers actually experience when they’re in flow, what interruptions are helpful versus annoying, what level of confidence justifies a suggestion versus a warning versus silence, how to present a fix so it teaches rather than mystifies.<br>The code for each inspection was straightforward — usually just one more visitor for an abstract syntax tree (AST) traversal. The decisions were where all the value lived. None of them were technical problems in any meaningful sense. The judgment was the whole game.<br>When senior engineers talk about those judgment calls, we reach for the word “taste.” We all know what we mean. We also all know we can’t quite say what we mean. And we’ve mostly stopped trying.<br>The most important concept nobody examines

Engineering taste might be the most under-theorized important concept in our field. We don’t have courses on it. We don’t have a taxonomy. We have a few books that gesture in its general direction — John Ousterhout’s A Philosophy of Software Design gets partway there, Steve McConnell’s Code Complete circles it — but nothing that constitutes a body of knowledge. When I went looking for a formal literature on the epistemology of engineering — not engineering ethics, but how engineers know — I found the shelves essentially bare. We have the apprenticeship model: you learn taste by working near people who have it, absorbing it through code reviews and design arguments and the occasional “no, not like that” delivered with varying degrees of tact. That’s it. That’s the curriculum.<br>This matters more now than it used to. The emerging consensus in our industry is that as AI handles more of the mechanical work of coding, what remains — what differentiates the engineer who builds the right thing from the one who builds an impressive wrong thing — is “taste” (also “business understanding”, but that’s always the case). Everyone nods wisely at this. Almost nobody has done any actual thinking about what taste consists of, how it develops, or how you’d go about teaching it. “What matters is taste” is a tautology wearing a beret and smoking a Gauloise, and I’d like to do better than that.<br>Full disclosure: I’m going to do only one little bit better than that. This is under-theorized territory, and I’m not going to theory it up to completion in a blog post. There’s probably a Ph.D to be gotten by thinking deeply along these lines, if you find yourself in the market for one. What I can offer is a first-pass decomposition — breaking one vague top-level concept into several vague-but-less-vague mid-level concepts, each of which is at least separately thinkable in a way the muddled conceptual dumping ground of “taste” isn’t. I’m groping, but I’m groping with intent. Gutter. Stars. Oh Muse, hear my prayer.<br>The Right Engineering Stuff, and the Problem of Quality

Tom Wolfe, writing about test pilots in The Right Stuff1, identified a dynamic that maps interestingly onto engineering taste. The “right stuff” was a tacit knowledge describing the skills, talents, and mindsets of elites in a field, the top test pilots who would eventually break the sound barrier and then become our first astronauts. The Right Stuff was universally recognized by those who had it, never directly spoken of, and functioned partly as a filtering mechanism for the priesthood. You either had it or you didn’t, and analyzing it too closely felt like it might jinx it. The ineffability was doing social work, enforcing the boundaries of the clique.<br>Engineering taste has a similar dynamic. Senior engineers recognize each other through taste and use its absence as a signal. But unlike Wolfe’s test pilots, we’re in a profession that supposedly values making the implicit explicit, and we certainly don’t truck in jinxes. We formalize everything else. We should at least try to formalize this.<br>The cautionary tale here is Robert Pirsig, who spent the whole of Zen and the Art of Motorcycle Maintenance trying to define “Quality” with a capital Q and mostly succeeded in demonstrating that unifying the concept into a single luminous metaphysical primitive is an embarrassing dead end. Pirsig had real insights — the motorcycle maintenance as a metaphor for caring about your work, the...