Back tostdlib
Blog Post
New

What Do Engineers Mean When We Say "Taste"?

Engineering taste is calibration across product thinking, system thinking, and quality - knowing which tradeoffs to make when building software. It's not mystical intuition; it's pattern-matching from experience combined with knowing what's technically possible.

Engineering taste is the integrated capacity to calibrate well across multiple domains simultaneously, grounded in deep knowledge of what is physically possible. When you're building software, you're not just writing code - you're adjusting dozens of interacting dials at once. How much effort versus value at every level from this function to this quarter's roadmap. When to build the abstraction versus hardcode the thing. When to follow existing patterns versus when those patterns are wrong for this case. The distance between knowing the right answer and having taste is the distance between competence and mastery.

The piece breaks taste into three components. Product thinking is building the right thing - calibrating what to build against what users and the domain actually need. System thinking is building so it survives contact with reality, understanding how coupling and cohesion feel before you measure them, sensing when a dependency graph is getting tangled before anyone draws a diagram. Quality as calibration means knowing where to be rigorous and where to be scrappy, understanding that a bad architecture thrown together fast might be the best architecture if time-to-market is decisive.

What makes taste impossible to reduce to a checklist is that these three domains aren't separable in practice. A product decision (we need this by March because marketing screwed up) constrains system decisions (we can't do the ideal architecture) which constrains quality decisions (this module needs to be scrappy because requirements are in flux, but this module on the critical path needs to be rock solid). The ability to hold all of that in your head at once, to feel the tensions between dimensions and find a satisfying-enough resolution - that's taste.

This is why the apprenticeship model persists and why computer science programs fail to teach it. You can't learn taste from lectures about algorithms or formal methods. You learn it by watching someone navigate a complex decision and absorbing not just the decision but the shape of the consideration. The junior engineer can't calibrate on "I've seen this movie before" because they haven't seen enough movies yet, especially not enough gory ones. You need the reps plus the reflective capacity to extract transferable patterns from them.

Source: davegriffith.substack.com
#engineering-judgment#software-architecture#product-thinking#system-design#code-quality#technical-decision-making#engineering-education#apprenticeship#calibration#tradeoffs

Problems this helps solve:

Technical debtDecision-makingCareer developmentKnowledge sharing

Explore more resources

Check out the full stdlib collection for more frameworks, templates, and guides to accelerate your technical leadership journey.