Live data from Hacker News

What is “good taste” in software engineering?

seangoedecke.com

121–130 of 245 posts

Re: What is “good taste” in software engineering?

#121

When used in the domain of fashion "good taste" describes someone who has a unique way of selecting clothes that just mesh well together - clothes that by themselves independently are meaningless, no matter their make or quality, but when combined together create a powerful effect - much greater than the sum of their parts. I was hoping the article would go in that direction - what subjective combination is a softwar…

You're comparing apples and oranges. Good taste in fashion is much more subjective than in software engineering, obviously because one stays a subjective discipline while the other always ends up in formal science.

What's interesting is that software engineering starts in social science where most choices are made subconsciously or at least not discussed with other people.

Re: What is “good taste” in software engineering?

#122
post #86

> In other words, immature engineers are too inflexible about their taste. They know what they like, but they mistake that liking for a principled engineering position. I have come across this although I think quite experienced engineers can suffer from this kind of immaturity. Aeons ago I used to help friends with their Computer Science assignments. I remember the temptation to rewrite their code because I didn't li…

This principle (sorry ;)) is applicable to all domains. I'd wish I would remember this more often. Thank you for the gentle reminder!

Re: What is “good taste” in software engineering?

#123

Having architected some large projects, then coded, then refactored because original designs didnt work out, eventually getting a working project that does things. Also now having done the same thing 95% ai coding. Good taste is good architecting. Knowing what to use; how to use it and when. How to maximize KISS. Simplicity is key. When is it right to keep it very simple and load it to a dict? When to upgrade to a pa…

Same here with regards to large systems, refactoring, and then getting things working.

I believe that is what builds taste: varied experience.

Re: What is “good taste” in software engineering?

#124

Good taste is writing code that looks so simple, everyone else says "pshaw, anyone could have written that!"

The challenge though is getting people to appreciate it, because the code looks / is boring as well. A lot of junior but good and driven developers (...myself included) want to write clever code, code that makes them feel smart, but often in an environment where the problem doesn't need it. CRUD back & front-end has this problem, where the complexity isn't (shouldn't be) in the code itself but the higher level stuff - domain, architecture, etc.

And then there's a class of people that overcomplicate the architecture out of boredom, perceived possible problems (like scaling) or cargo cult, and they introduce stuff like microservices or lambdas instead of just solving the problem at hand with proven and simple solutions.

But you won't find good developers if your job listing is "looking for a java developer for a straightforward CRUD application".

Re: What is “good taste” in software engineering?

#125
post #86

> In other words, immature engineers are too inflexible about their taste. They know what they like, but they mistake that liking for a principled engineering position. I have come across this although I think quite experienced engineers can suffer from this kind of immaturity. Aeons ago I used to help friends with their Computer Science assignments. I remember the temptation to rewrite their code because I didn't li…

This is why I like experimenting with lots of different programming languages, and why I try to make the next language to understand as different as the ones I know, as I'm having these "epiphanies" all the time, challenging my existing views, which I can apply across languages when suitable. You just need to accept that things feel "wrong" and "weird" initially, before you've grokked the whys and hows.

Re: What is “good taste” in software engineering?

#126
post #110

Earlier quoted context omitted.

> Readability is a non-concept really Yes.

Readability without a clarification is a non-concept. You can't say "X should be readable" without giving some context and without clarifying who you are targeting. "Code should be readable" is a non-statement, yes.

Add "to most developers" for context and you'll probably get exactly what original claim meant.

It's not a non-statement. Rich Hickey explains it well, readability is not about the subjective factors, it's mostly about the objective ones (how many things are intertwined? the code that you can read & consider in isolation is readable. The code that behaves differently depending on global state, makes implicit assumptions about other parts of the system, etc - is unreadable/less readable - with readability decreasing with number of dependencies).

Re: What is “good taste” in software engineering?

#127
post #78

Earlier quoted context omitted.

> You break up things when it makes sense, not for the sake of it. I never claimed otherwise. > Having to jump out of the code you're reading comes with its own downsides and tends to compromise maintainability where you are increasing the shallowness of your code (higher api surface). I don't buy this argument. The code you're reading should do one thing according to what it says on the tin (the function name). When…

> Eh, I'm not swayed by arguments from authority. Jon's opinion is as valid as mine or yours. John has spent his entire life to learning and teaching general principles of good software design and their limits. His opinion definitely has a different weight than ours. https://web.stanford.edu/~ouster/cgi-bin/cs190-winter21/inde...

Well, he can start citing Martin Fowler or Bertrand Meyer. Then what?

Arguments from authority lead no where here. Because these "authorities" also disagree.

Re: What is “good taste” in software engineering?

#128
Since this is just arguing over a definition, the best take I can give is what definition has proved most useful to me in the past. That is thinking of taste as the ability to recognize something as good or bad when seeing or hearing a description of it, usually without it actually existing.

Let's say I have a plan for a new feature and a way of building it, if I show it to someone with good taste, they will be better at telling me if it's going to work out, and how valuable it will be to users, than someone with bad taste.

Viewed this way, it's almost quantifiable, and at the very least: good developers can usually agree on who has good taste. You can tell based on their actions not words. They will go out of their way to get feedback from people with good taste. IME the people with the best taste for a product are power users and evangelists.

Re: What is “good taste” in software engineering?

#129

Earlier quoted context omitted.

> Eh, I'm not swayed by arguments from authority. Jon's opinion is as valid as mine or yours. John has spent his entire life to learning and teaching general principles of good software design and their limits. His opinion definitely has a different weight than ours. https://web.stanford.edu/~ouster/cgi-bin/cs190-winter21/inde...

Well, he can start citing Martin Fowler or Bertrand Meyer. Then what? Arguments from authority lead no where here. Because these "authorities" also disagree.

John has had meaningful impact to computing from algos, operating systems, programming languages, frameworks, etc.

Fowler has written *nothing* anybody ever cared for. Nothing.

Ousterhout has taught Software Design at Stanford where he's had students implement the most diverse software and finding the limits of his own theories and having them questioned rigorously year after year.

Re: What is “good taste” in software engineering?

#130
This might count as "Readability" but it is more structural. If it is easy to remember how a system works it is a real benefit. This isn't traditional "simplicity" necessarily either. A system containing a lot of simple code doing simple things, together might be hard to remember in aggregate. I'm not sure what this metric is called but if I can't remember how something works a year after creation, it fails the test.
Post reply on HN