Ask HN: Ideas to acquire "good taste" in programming?

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

Less is more.

The more senior you become the less you need to accomplish ever more ambitious products. Applying some Cartesian logic to programming you will realize there are few unavoidable aspects of programming and everything else should generally be avoided. Consider these:

* flow control

* transmission

* data structures

* operators

Those things are necessary as avoiding them becomes more costly than not. So, use that to your advantage. Write code knowing you must master those and they become the principles on which everything is created. So, you know what the foundation looks like and generally know what the end state looks like. Good taste is how elegantly you can populate that massive gap between foundation and end state.

Most programmers completely miss this line of thinking and instead spend all their energy applying unnecessary code decorations, which I call lipstick on a pig's asshole. Instead solve the problem as directly as possible and reuse common solutions where convenient. Finally, structure and/or describe the code such that the actual flow control, such as the stack trace, directly reflect the logic as easily read by a human.

After some practice programming like this you will form instant visions for solving challenging problems. The structure of the code will just appear in your head faster than your fingers can type it into a keyboard. You will have put the Lego pieces together so many times that you will just know how to build that world-class cathedral without thinking in terms of the Lego pieces. If instead you need unnecessary code decorations you will continue to think about which Lego piece is most beautiful instead of just building the damn cathedral.

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".

I think it's more of picking the right problem than getting the right skills. If you have to write a lot of business logic in the code, as a FE or BE or DE or whatever, I believe you will never acquire "good taste" in programming because you are fighting against the culture of "ASAP", "Fast iteration", etc.

You should pick system programming jobs, preferably in a good team with a good manager.

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.

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.