the best engineers i've worked with have a quality that's genuinely difficult to name and even harder to hire for. it's not raw intelligence — i've worked with very intelligent engineers who produced systems that were unnecessarily complex, fragile, and unpleasant to maintain. it's not years of experience — i've worked with experienced engineers who kept reaching for the same solutions regardless of fit. the closest word i have is taste. and taste is, i think, the central underrated quality in software engineering.
taste is not about aesthetics in the superficial sense — it's not about code formatting or variable naming conventions or whether you prefer functional or object-oriented style. those are preferences. taste operates at the level of the system. a person with taste will design an API that feels natural to consume six months later, after the person who built it has left. they'll choose a data model that accommodates the next three features without anyone having planned for them. they'll look at a technically correct solution and feel that something is wrong before they can articulate what. they'll know when a refactor adds genuine value and when it's just self-indulgence dressed up as improvement.
where does taste come from? i think two things: exposure and pain, in roughly equal measure. exposure means you've seen a lot of systems — not just the ones you built, but the ones you read, debugged, inherited, and had to extend in ways the original author never imagined. you've accumulated an internal library of what works and what doesn't, not as abstract principles but as specific memories. you remember the time a data model that seemed elegant made the next three years of feature work harder than necessary. you remember the system that was built with appropriate simplicity for its moment and scaled gracefully when the requirements grew. these experiences are the substrate of taste.
pain is the necessary accelerant. there is a difference — enormous, in practice — between reading about why certain architectural choices are problematic and being the person paged at 3am because a decision you made six months ago has started failing in a specific load pattern. the post-mortem reading gives you information. the 3am page gives you judgment. reading is necessary but insufficient. you need to have shipped things and watched them break, in real production, with real consequences. that feedback loop, however unpleasant, is what turns knowledge about engineering into intuition about engineering.
taste cannot be directly taught, which creates a genuine pedagogical problem. you can teach someone to write tests. you can teach them to document their interfaces. you can explain the principles behind separation of concerns or why global state is dangerous. you cannot teach them to feel when an abstraction is doing too much, before the abstraction has caused problems, before the feeling can be backed by evidence. taste requires the pattern recognition that comes from experience, and experience requires time.
what you can do is create environments where taste develops faster. code reviews that ask "why did you design it this way" instead of just catching bugs. pairing sessions where the senior person narrates their reasoning — including their doubts and their rejected alternatives — rather than just producing correct solutions. post-mortems that examine "what did we believe at the time that turned out to be wrong" rather than "whose fault was this." the common thread is making the reasoning process visible, so that junior engineers can observe the quality of judgment rather than just the output of judgment.
the best engineering cultures say "I don't know" and "it depends" with high frequency. this is a sign of health. taste thrives in ambiguity — it's exactly the skill that becomes valuable when the answer is genuinely unclear and requires judgment rather than technique. environments that worship certainty — that want every decision to have an obvious right answer backed by best practices and industry consensus — select against taste and select for compliance. compliance and taste are different things. you want teams with taste. they're harder to manage and more difficult to interview for, and they build systems that last.
if you're early in your career: taste develops slowly and cannot be rushed. the most useful things you can do are read other people's code critically (not just "does this work" but "what would happen if we needed to change X or add Y"), ship things, and pay close attention to what breaks and why. the rest takes care of itself, slowly, over years.