> good taste is the ability to select the right set of engineering values for the particular technical problem you’re facing
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.
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.