Engineering Taste and Technical Judgement

The Microservices MVP

A team building an early product decides to start with microservices. The architecture sounds modern. Each domain will have its own service. Every service will have its own database. Events will connect everything. The diagrams look impressive.

Six months later, the team is slow. Local development is painful. Simple changes require coordination across services. Debugging takes too long. The product direction has changed twice, but the architecture hardened too early.

Another team in a similar market starts with a modular monolith. The boundaries are clear inside the codebase, but deployment is simple. The team ships faster, learns faster, and extracts services only when the boundaries become real.

The second team did not choose a less serious architecture. It chose a more appropriate one.

That is engineering taste.

What Taste Really Means

Engineering taste is the ability to choose what is simple, durable, changeable, and appropriate for the context.

Taste is not personal preference. It is not "I like this framework" or "I dislike that pattern." Taste is accumulated judgement about consequences.

Good taste asks:

What problem are we solving?
What stage is the product in?
How likely is this area to change?
What failure would be expensive?
What complexity is justified?
What can we defer?
What will future engineers understand?

Bad taste often hides behind sophistication. It chooses impressive tools before the problem earns them.

Simple Versus Simplistic

Simple means understandable and sufficient.

Simplistic means ignoring important reality.

A simple solution handles the important cases with minimal moving parts. A simplistic solution handles the happy path and collapses under real use.

Builders are not obsessed with minimalism for its own sake. They are obsessed with appropriate complexity.

Payment systems need more care than marketing pages. Authentication needs more rigor than an internal prototype. A one-off admin script does not need the same architecture as a customer-facing platform.

Taste is proportional.

When to Abstract

Abstraction is useful when it reduces real complexity or protects stable boundaries. It is harmful when it guesses too early.

Abstract when:

You have repeated behavior with clear similarity.
The concept is stable.
The abstraction improves understanding.
It reduces change cost.
It creates a boundary the business recognizes.

Wait when:

You only have one example.
The product direction is uncertain.
The abstraction name is vague.
Future requirements are guesses.
The abstraction hides important differences.

AI can generate abstractions quickly. That makes restraint more important.

The Taste Filter

Before approving a technical solution, run it through the Taste Filter: pass every technical option through these six questions, in order, before it reaches an appropriate solution.

Understandable: can the next engineer read it without a walkthrough?
Changeable: how easily does it absorb a requirement that shifts?
Observable: can you tell what it is doing in production?
Reversible: how expensive is it to undo?
Proportional: does its complexity match the problem's size?
Future cost: what does it cost the team a year from now?

No solution passes every filter perfectly. Trade-offs are normal. The goal is to make them explicit.

Trade-Offs as First-Class Decisions

Immature teams argue as if there is one correct answer. Mature teams compare trade-offs.

For example:

Option A: Patch the current billing logic.

Fastest.
Higher regression risk.
Keeps future pricing changes slow.

Option B: Isolate discount rules first.

Takes longer now.
Reduces future change cost.
Safer for planned pricing experiments.

Option C: Rebuild billing module.

Cleanest long-term design.
Too expensive for current timeline.
High migration risk.

A builder can recommend Option B without pretending it has no cost.

Architecture Decision Records

An Architecture Decision Record, or ADR, captures why a technical choice was made.

It should include:

Context.
Decision.
Options considered.
Trade-offs.
Risks.
Reversibility.
Business impact.
Review date.

ADRs are not bureaucracy when they are short and useful. They prevent teams from relitigating decisions without context.

Founder Lens

Bad engineering taste burns founder money silently. The product may appear to work, but every change becomes slower. Hiring becomes harder. Bugs become stranger. AI-generated code adds volume to systems nobody understands.

Good taste protects future speed. It keeps the company able to change direction.

Developer Lens

Taste grows through review and reflection. After technical decisions, ask:

What did we expect?
What happened?
What became easier?
What became harder?
What would we choose next time?

Study production outcomes, not only code style.

AI-Era Lens

AI often produces plausible average solutions. Taste is what helps you decide whether average fits your context.

Ask AI for multiple options and trade-offs. Do not ask it to choose blindly. Feed it product stage, team size, risk level, expected change, and operational constraints.

Common Mistakes

Confusing impressive architecture with good architecture.
Abstracting before patterns are real.
Rejecting simple solutions because they feel less senior.
Treating trade-offs as weakness.
Copying architecture from companies with different constraints.
Letting AI generate structure without human taste.

Builder Checklist

I can explain why the chosen solution fits this context.
I can name the trade-off we are accepting.
I can identify where the system is likely to change.
I can avoid premature abstraction.
I can use ADRs for important decisions.
I can evaluate AI output with the Taste Filter.
I can choose boring technology when boring is right.

Exercise: Apply the Taste Filter

Choose one recent technical decision. Score it from 1 to 5 on each Taste Filter question. Then write what you would keep, change, or review later.

Closing Thought

Good engineering is not about using impressive tools. It is about making appropriate decisions.

Key takeaways

Engineering taste is accumulated judgement about consequences, not a preference for a framework: it is proportional to what is at stake.

Simple means understandable and sufficient; simplistic means the happy path works and everything else collapses under real use.

Abstract only once you have repeated, stable behavior; wait when you only have one example or the direction is still a guess. AI makes premature abstraction cheap to produce and more important to resist.

Compare trade-offs explicitly (Option A/B/C, each with its real cost) rather than arguing for a single "correct" answer, and record the reasoning in a short ADR so the decision survives the person who made it.