What is “good taste” in software engineering?

Experience does not always result in maturity. It is actually pretty common for engineers to become more set in their ways as they gain experience, especially if they've seen some success, because that success has convinced them that the way they do things is the right way.

> Which design decisions you feel really good about, and which ones are just fine? It's not just a feeling, it comes from reasoning.

Good taste == good skill isn't it?

When someone chooses a functional lang over an object oriented one - is this because of better taste? They’ve learned, through experience, what kinds of problems map more cleanly to immutability and composition versus encapsulation and state. Their "taste" for one paradigm over another is just a reflection of the skills they’ve built up in recognizing tradeoffs, debugging pain points, and anticipating long-term maintainability. What looks like taste is really just expertise shaping intuition.

I get why the author feels a team member who doesn't align with the team's goals has bad taste. But it's really just this - the opinions they have formed from their experience don't match yours.

I don't think this makes sense. Firstly because engineering values aren't the same thing as engineering requirements; I don't want someone's "values" to end up making a product unsafe or unreliable (these aren't "taste", they're non-negotiable requirements). But secondly because, in engineering at least, your personal opinions shouldn't matter.

Taste is all about opinion and self-expression. Your taste is different than my taste? That's fine. Your engineering is different than my engineering? That's not fine. The same building, with the same architectural plans, same location, same everything, shouldn't be built 6 different ways depending on the "taste" of the engineer. Trusses and struts aren't to your "taste"? Tough luck, buddy. Engineering is about precision, science, math. It's not a plate of spaghetti.

A PR could be said to be a "review of taste", that nit-picks in a PR are just judgements of personal taste. But that's not what PRs are supposed to be. They're actually a replacement for QA. In normal products, a Quality Assurance process is a secondary one that verifies products are built correctly. But in software engineering today, PRs take the place of QA (and design reviews). This means a PR isn't about taste, but about quality.

Higher quality implies good taste, but they aren't the same thing. Style, fit, context, etc are as much a component of "taste" as quality is. Therefore I think "taste" in software engineering should be limited to the optional or irrelevant parts. All the things that you care about, but don't actually affect the engineering quality of the end result. And if that's true, then it means we probably need to have hard definitions of what affects engineering quality.

For example: most people would argue that variable names are very important. That how you name a variable affects its "maintainability". But in reality, the names could be random, and the program would operate the same way. That doesn't mean that variable names are irrelevant. But it does mean there's a categorical difference in what it is, and why it's important. That needs to be codified and taught to new CS students.