What is “good taste” in software engineering?

While balancing that to performance requirements appropriate for the project. And picking dependencies that do the same while having a healthy community likely to keep going.

The same applies to picking vendors, asking questions like "will they extort me next contract renewal" and "what options do I have if they extort me".

Spaces have won already. It is the default setting across code editors now.

> In my view, your engineering taste is composed of the set of engineering values you find most important. For instance:

Strange how absent the customer or underlying business always is in this discussion.

I've seen a LOT of software that could have literally just been a spreadsheet on a file share or a simple SQL ETL job. When reviewing the actual business requirements, we will often find that we don't even need a goddamn web interface. It's just assumed we're gonna build some full stack slop so we never bother to stop and ask why.

I'm watching a client (despite my advice) self destruct on yet another rewrite of a piece of software that doesn't need to exist in the first place. Looking forward to having this exact same conversation IRL in a few months.

I think the heart of bad taste comes from obsessing over tools and techniques and not ever getting meaningful things built and shipped to real customers. Being exposed to unfiltered criticism of the people who actually use your software is the fastest way to drive the noob behavior out of a developer. It's amazing how quickly you drop weird principled takes when your monkey brain senses it is disappointing others.

I would say limiting the braggadocio is important to "good taste" as well. I interviewed once for a dev role on the email team for a very large free software company you've heard of. The team's egos were so large I could hardly fit in the room. "Oh! I see you wrote the control system for a nuclear power plant. That's cute, I once inverted a tree data structure!" or "I see you wrote the modular exponentiator that was in half the ATM machines deployed in the US in the mid-90s. Whatever. I wrote code that changes the background color of our web page."

I did not take the job.

> Is the software easy to take in at a glance and to onboard new engineers to?

This is not as easy as it sounds. Who are those "new engineers", juniors? 10 years of experience? 30 years? What's your requirement?

"Readability" is such a wildcard, with a whole range of acceptable levels from zero to infinity. Readability is a non-concept really. Maxwell's famous equations are readable to some and absolutely impenetrable to the rest of us.

So when someone says "code should be readable", to whom exactly?