What is “good taste” in software engineering?

What “Good Taste” Might Mean

• Many see “taste” as the set of engineering values you prioritize (readability, performance, flexibility, etc.) and how you balance tradeoffs in a specific context.
• Others argue “taste” is a poor label for what’s really intellectual humility and principled decision-making, not aesthetics.
• A skeptical camp says “good taste in software” sounds narcissistic and is too subjective to be used in evaluation or hiring.

Subjective vs Objective Judgments

• Some decisions are called objectively bad (e.g., obviously inefficient data structures), where “taste” isn’t relevant.
• For most design choices, there are tradeoffs; “taste” is the judgment of when a tradeoff is worth it.
• Several commenters prefer framing things as explicit principles (“minimize mutability”, “optimize for determinism”) rather than vague taste.

How Taste Develops

• Widely agreed that taste comes from experience, especially maintaining others’ “clever” systems over years and seeing what ages badly.
• Working across many domains, stacks, and both “good” and “bad” codebases sharpens intuition about complexity, future change, and failure modes.
• “Broken compass” metaphors:
  • Obvious bad-taste engineers are easy to filter.
  • More dangerous are partially competent devs (cargo‑cult, tutorial‑only, LLM‑dependent, edge‑case layering) who scale systems until they fail catastrophically.

Examples of Good vs Bad Taste

• Good taste associated with:
  • Simple, boring, composable code; minimal cognitive load.
  • Clear separation of concerns (e.g., pure logic vs input parsing).
  • Small, targeted changes for new features; APIs that centralize edge‑case handling.
  • Picking stacks and infra that can be swapped or evolved.
• Bad taste associated with:
  • Overcomplication, premature abstractions, unnecessary frameworks/microservices.
  • Copy‑paste, ignoring abstractions, or forcing one paradigm everywhere.
  • Building full systems where a spreadsheet/ETL + CSV export would suffice (though some caution that spreadsheets become fragile at scale).

Readability and Simplicity Debates

• Strong debate over what “readable” means and for whom; readability seen as audience‑dependent but not meaningless.
• Some argue function length is a poor proxy; others say long functions harm comprehension and testability.
• Many converge on: readable code minimizes cognitive load, hides incidental complexity, and is easy for a typical mid-level engineer on the team to change.

Ego, Collaboration, and Hiring

• Bragging and “lecturing on taste” are seen as red flags; humility and empathy for future maintainers are praised.
• “It depends” and the ability to explain tradeoffs are viewed as signals of maturity.
• Using “taste” as a hiring filter is seen as risky: it can become a justification for hiring only like‑minded people instead of assessing concrete skills and behaviors.