Witnessing and dealing with some mess among other things helps to understand few unpleasant but important to swallow pills:

1. Code is not an asset, it’s a liability

2. Code is not a piece of art its a plumbing behind the scenes. It doesn’t has to be fancy and elegant. But it must be effective and both easy and cheap to maintain.

3. Most engineers engineer for the sake of it, and this leads to a mess.

4. Most important code quality metrics is a team scalability. Optimizing code for maintainability and simplicity is way more important and profitable than optimizing for anything else.

I think as with any taste it can’t be learned explicitly. It’s an accumulation of many real world examples of good and bad decisions.

But something you can accelerate by jumping on a harder problems and diving into larger projects.

The best way is to have a mentor. You can't beat that (in programming, as in life and any other discipline).

Second best, is looking at how the best people in the company I work for solve problems. Still takes a lot of time and effort, but I found it's well worth the effort.

As for books, A philosophy of Software Design by John Osterhout and Domain-Driven Design by Eric Evans are the ones I've found the best impactful for 'good taste'.

1. Focus on shipping stuff

Shopping something mediocre is better than not shipping anything

2. Read (and understand) good code in many different languages

Learn concepts not frameworks

3. Understand compilers and their design

Understanding these fundamentials will improve your skills in many ways

4. learn how to read official docs

See tutorials and Videos as secondary source, official docs have mich higher information density

5. learn to use tools

Git, Ai, sonarcube and others are helpful tools... Learn about Them.

6. have private projects

Best case something you use yourself and you're passionate about

Getting disgusted by seeing unnecessary complex and obfuscated code, and seeing how my own naive most obvious and intentfully explicit code describes the program execution like a story.

Oh, and if you have opportunity to start the codebase from scratch, making one semantic change per version control commit is insanely powerful explainer of how/why your code became as it is. They are like chapters/paragraphs in a story.

Also, separation of concerns: having clear separation of libraries and your "own" code. Including not mixing "business logic" (changing human rules/parameters/requirements) with technical non-human machinery.

If you don’t understand what matters in your domain, you’ll waste time polishing the wrong parts.

In AdTech, milliseconds and malformed VAST XML matter more than beautiful abstractions. If I were in game dev or finance, it’d be something else.

Good taste comes from knowing where to be precise and where to be pragmatic I believe.

Reading other people’s code — especially well-crafted open source projects — helped me internalize patterns, see alternate approaches, and spot elegance.

You learn what not to do just as much as what to do.

Working in a team and peer reviewing each others code was definitely what teached me most. It did help a lot that one of my team members was also a dev of that specific tool.

Refactoring, taking my time to do so and learn new things to optimize while doing so is what helps me most today.

AI for some reason is totally not helpful for my vision of clean code.

Self-host all the things of the kind you want to absorb. Including the builds. Use it in anger.

Pull at the bugs. Look if you can add the missing features (And later, fix the bugs that came from your patches)

Pay attention to what pisses you off and what doesn't over time.

Reading good books and good code is important.

In my case, I found the code in AIMA and CTM very inspiring.

I think it takes being on a project for several years, more than once. You need to see some good ideas turn out to be bad ones, or at least to have some bad side effects. You need to see some features that were developed that turned into maintenance headaches (and some clever hacks that did, too). You need to bump into the issues that the architecture causes, repeatedly.

I think understanding the longer-term consequences of ideas that sound good in the short term is a big part of "good taste".