What Do Engineers Mean When We Say "Taste"?

Toward a decomposition of the least-examined concept in software engineering

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.

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.

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.

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.

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.

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.

The Right Engineering Stuff, and the Problem of Quality

Tom Wolfe, writing about test pilots in The Right Stuff¹, 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.

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.

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 distinction between the romantic and classical understanding of a machine, and the brute fact that these are realms worthy of philosophic investigation. But his attempt to make Quality into a foundational category of reality rather than decomposing it into workable components is exactly the failure mode I want to avoid.

So rather than trying to define taste as one thing, I want to break it into its major constituents and see what we can learn by examining them separately. Engineers decompose problems, after all. I’ve been waiting for someone to do this since I was sixteen and got book-throwingly upset when Pirsig punted and equated Quality with the Dao. Four decades later, I’m still waiting, so I might as well take a crack at it myself.

Taste as calibration

Here’s my thesis: engineering taste is the integrated capacity to calibrate well across multiple domains simultaneously, grounded in a deep knowledge of what is physically possible.

Calibration is the right word because it captures something that “judgment” or “intuition” doesn’t. When you calibrate, you’re finding the right setting along a dimension, and you’re doing it in context — the right setting for this situation. I use the (somewhat made up) word “tradespace” to get this idea across to clients and suits. Engineering taste is calibration in a moderately high-dimensional manifold (low hundreds, not millions). You’re adjusting dozens of dials at once, and the dials interact.

Some of the dimensions you’re calibrating along:

• Effort versus value — and this at every granularity, from this function to this module to this quarter’s roadmap.

• Generality versus specificity — when to build the abstraction and when to hardcode the thing.

• Consistency versus fitness — when to follow the codebase’s existing patterns and when those patterns are wrong for this case.

• Robustness versus velocity — and crucially, this isn’t a single global dial; it varies by component based on blast radius.

• Explicitness versus concision — verbose legible code versus elegant dense code, and knowing which context demands which.

• Present needs versus future optionality — “YAGNI” (“You Aren’t Gonna Need It”) versus “I’ve seen this movie before, and we’re going to need this.²”

That last one is where experience is most clearly load-bearing. “I’ve seen this movie before” is the pattern library that underlies taste. A junior engineer can’t calibrate on that dimension because they haven’t seen enough movies yet, and especially not enough gory ones. This is where the common explanation of taste as “very good intuition built from a huge number of reps” is necessary but insufficient. You need the reps plus the reflective capacity to have extracted transferable patterns from them.

The three major domains in which taste operates, as far as I can tell, are product thinking, system thinking, and what I’ll call quality-as-calibration. All three are forms of calibration. All three depend on knowing what is possible.

Product thinking

Product thinking is taste as building the right thing. It’s calibrating what to build against what users, the market, and the domain actually need.

This is the component of taste where “knowing what is possible” is most dominant and also most poorly served by existing engineering education. Computer science programs teach system thinking in a few domains (algorithms, architecture, distributed systems). They teach quality in a narrow sense (testing, formal methods). They teach approximately zero product thinking. You learn it by shipping things and watching what happens, which is another way of saying it’s pure apprenticeship knowledge with no formal curriculum — and possibly the single biggest gap in engineering education.

The engineer with product taste knows which features will compose well, which abstractions will serve users (including technical and non-technical users), where simplicity is a feature and where it’s a cop-out. They have a rich enough mental library of solutions that they can pattern-match a problem to an approach that fits rather than one that merely works. The distance between “works” and “fits” is the distance between competence and taste.

Blog-favorite David Chapman, writing from an epistemological perspective on his Meaningness Substack, puts his finger on something important here: the purposes of software are irreducibly nebulous. The people who will use the software don’t fully know what they want. They can’t envision what the technology might do for them. Non-technical stakeholders don’t know what’s technically feasible, so they ask for the impossible while failing to ask for the useful. Product taste is the capacity to navigate this nebulosity — to hold the vague, shifting, partially-contradictory cloud of “what is needed” in your head and make concrete decisions that serve it well enough to be going on with.

System thinking

Every mental construct is an approximation. Every interconnection is a place where something can and eventually will go wrong. Every dependency is a hostage to the universe’s underlying chaos. “System thinking” is the name for the methods of thought we use to build in spite of these hard truths.

If product thinking is about building the right thing, system thinking is about building the thing so it survives contact with reality. It’s taste applied at the architecture level — the temporal dimension of calibration. Which parts of this system will need to change? Make those parts easy to change. Which parts are stable? Make those simple and rigid. How does this subsystem fail? What’s the blast radius when it does?

System thinking includes the topological intuition that experienced architects develop — understanding how coupling and cohesion feel before you’ve measured them, sensing when a dependency graph is getting tangled before anyone’s drawn a diagram. It’s the ability to envision the ghostly future form of a system that doesn’t exist yet and make commitments now that your future self won’t regret.

Chapman, in his treatment of software architecture, observes that there are no professional standards for software architecting, no generally recognized methods, and that university courses are rare and lack substance. He’s right. The books on software architecture mostly describe the work in extremely abstract terms, and their methods aren’t all that actionable. In practice, you learn it informally — through apprenticeship, through jokes that are funny because true, through doing it badly and discovering the consequences two years later. We codify everything but ourselves.

What system thinking is, at a cognitive level, is maintaining a mental model that spans multiple levels of abstraction simultaneously — connecting the real world of users and business constraints with the formal world of data structures and interface protocols — and noticing when details at one level have implications at another. The architect who discovers that seemingly minor details of an invoice format have crucial implications for data model design and thus for the persistence layer consistency protocols used is exercising system taste.

Quality as calibration

Quality is the trickiest component because it’s where taste gets most circular. “Good taste means knowing what quality looks like” sounds like it explains something, but it doesn’t. What it actually means, I think, is calibration: knowing how much quality is appropriate where.

The engineer with quality taste doesn’t gold-plate everything. They know where to be rigorous and where to be scrappy. They know that a bad architecture thrown together as fast as possible might be the best architecture if time-to-market is the decisive factor. (Engineers hate to hear this, but software doesn’t exist for the sake of elegant engineering; it exists to meet people’s needs, which may include “now.”) They also know when cutting corners will create compounding debt that cripples the system within eighteen months.

This is calibration in the full high-dimensional sense. You’re simultaneously calibrating test coverage, code clarity, documentation thoroughness, error handling robustness, performance optimization, and a dozen other quality dimensions — and the right answer for each one depends on the others and on context that may be shifting under your feet.

The integration problem

I’ve described three domains as if they’re separable, but the hallmark of genuine taste is that they aren’t — not in practice. The architect with taste is making product, system, and quality calibrations simultaneously, and the calibrations interact. A product decision (we need this feature by March because marketing screwed up, like, royally) constrains system decisions (we can’t do the ideal architecture, so get over your Haskell obsession, BOB) which constrains quality decisions (this module needs to be scrappy because requirements are still in flux, but this module, which sits on the critical path, needs to be rock solid so that our executives don’t have to testify before Congress. Again.³).

The ability to hold all of that in your head at once, to feel the tensions between the dimensions and find a satisfying-enough resolution — that’s the integrated capacity I’m calling engineering taste. It’s why taste can’t be reduced to a checklist. Checklists are one-dimensional; taste is the thing that operates across all the dimensions at once.

This is also why the apprenticeship model persists. Taste transfers through proximity because what the apprentice absorbs isn’t a set of rules but a way of calibrating. They watch someone with taste navigate a complex decision and they don’t just learn the decision — they learn the shape of the consideration. Over many such observations, plus their own reps with feedback, they develop their own calibration capacity.

Future Work (Man, how easy is that section header!)

I want to close by being honest about how much remains unexamined. This decomposition — product thinking, system thinking, quality as calibration, all grounded in knowing what’s possible — is a first pass. The mid-level concepts are less vague than the top-level concept, but they’re still plenty vague. I haven’t said anything actionable about how to develop taste, only about what taste is. I haven’t addressed whether taste can be taught at scale or whether the apprenticeship model is a fundamental constraint. I haven’t addressed whether engineering taste in this sense can be automated, although there are certainly glimmers in that direction. I haven’t addressed how taste varies across domains — whether the taste required for building developer tools is the same capacity as the taste required for building consumer products or embedded systems.

What I’ve tried to do is move the conversation from “taste matters” (which everyone agrees with, vacuously) to “here is what taste is made of” (which almost appears to have never been attempted). If AI continues to absorb the mechanical work of engineering — Spoiler Alert: It will — then taste becomes the bulk of the discipline, not just the part you muse about over a glass of port. That makes these investigations matter in a way they perhaps didn’t when we could get by on craft alone.

We need to do better than nodding wisely. This is my attempt to start.

---

Thanks for reading Dancing with Robots! This post benefited from extensive collaboration with Claude Opus 4.6. If Claude succeeds in developing engineering taste, I’ll mostly be here for the jokes.

1. Apropos of nothing, here’s the first scene of the movie version of The Right Stuff, not much more than Wolfe’s words narrated by Chuck Yeager, and just about the best cold-open in film history. (Yes, I know about The Matrix, and Raiders of Lost Ark, and Scream, and Jaws. Saving Private Ryan, maybe I’ll grant you.)

2. Also we’re going to need a bigger boat. And bring me the head of Alfredo Garcia.

3. I really should talk about my time on the CNN Election Night system some day.