Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What is “good taste” in software engineering?

seangoedecke.com

Post reply on HN
Print view View original

71–80 of 245 posts

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

#71

Post by t43562 »

gyulai wrote: post #9

Lecturing on "good taste" is a huge red flag for narcissism. "Taste" implies subjectivity. Pairing it with "good" is presupposing something along the lines of "my subjective evaluation of things is superior to yours", or "my subjective choices are superior to yours".

I think taste is one of those things that we use to describe something that is a bit difficult to judge.

Something might not be to my taste but it can be good and workable nonetheless. It has taken some decisions that lead to solving a problem in a certain way and I can see that that way works and can be extended but it might not be a way that pleases me. Perhaps this is because it forces me to think in a mode that I am not generally accustomed to.

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

#72

Post by epolanski »

imiric wrote: post #67
epolanski wrote: post #43

> Are functions relatively short and named well? I was hoping we moved beyond this "clean code"-ish nonsense of functions having to be short. Quality of a software design, maintainability, etc, have virtually no relation to length of functions and the most respectable software out there contain functions hundreds if not thousands of lines of code long without being impacted by its own weight.

Eh, hard disagree. (Though I didn't downvote you, since it's silly to downvote out of disagreement...) Readability, while subjective, plays a large role in software maintenance. Developers will be more reluctant to change code they don't understand, and more likely to introduce bugs. "Long" functions require following large blocks of code that work within the same context, and relying on comments to explain functiona…

You break up things when it makes sense, not for the sake of it.

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 (same functionality, but higher api surface).

You break up things when there are benefits to breaking them and Unix provides a very sensible reference to this topic where plenty of syscalls run generously in the thousands or tens of thousands of lines.

Stanford professor Jon Ousterhout (among other things the author of the Tcl language, the Tk framework, the Raft consensus algorithm and many other things) has an entire paragraph in his book "A philosophy of software design"[1], on why the argument "functions should be short" is short sighted and should never be taken at face value.

[1] https://www.amazon.com/Philosophy-Software-Design-John-Ouste...

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

#73

Post by medstrom »

OtherShrezzing wrote: post #6

> One interesting consequence of this is that engineers with bad taste are like broken compasses. If you’re in the right spot, a broken compass will still point north. It’s only when you start moving around that the broken compass will steer you wrong. Likewise, many engineers with bad taste can be quite effective in the particular niche where their preferences line up with what the project needs. This paragraph real…

Can you paint an example of a "partially broken compass" engineer?

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

#74

Post by bryanrasmussen »

necklesspen wrote: post #21

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…

> what subjective combination is a software engineer deciding on that you can argue is truly a matter of taste and not just a technical decision about a trade-off.

I put down to taste many things that I believe are technical decisions about trade-offs but that I cannot absolutely verify or which I believe the trade off is so very small that it doesn't actually matter.

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

#75

Post by jm547ster »

blub wrote: post #44
necklesspen wrote: post #21

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…

Most engineers and technical persons don’t have good fashion taste, so they have a hard time understanding good taste in general. The great majority of technical things are not cool to normal humans, they’re geeky. Programming languages are not cool. In programming one has to therefore start from “not cool” and move down the scale: Uncool: Rust, C++, most languages Painfully uncool: anything functional and weird. Bas…

Yeah the Linux language gets most people's goats......

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

#76

Post by pyrale »

WalterBright wrote: post #10

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

Obligatory simple made easy.

Just because something is simple doesn't mean anyone has the wherewithal to understand it.

[1]: https://www.youtube.com/watch?v=SxdOUGdseq4

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

#77

Post by t43562 »

gyulai wrote: post #34
antirez wrote: post #13

Earlier quoted context omitted.

That's exactly how it works in most fields that are not purely engineering but where the space of design solutions to do X is huge. Architecture, software development, ...

If I correctly catch the drift of your argument, you're saying “engineering is objective”, so there is such a thing as a right and wrong choice in any given situation. ...well, to the extent that that's true, the word “taste” is a poor choice of words then. Actually, I think that's the case for this article. I think the article is fine, but the title and “taste” as a choice of word is not great. The article is more a…

I couldn't say emacs developers have poor taste but I could say its' not my taste. I don't have to disrespect them. People think in different ways and get used to different things.

e.g. I might decide that some clothes, although well made and possibly even very fashionable, are not my taste. The superiority/inferiority of taste is something that insecure people focus on IMO. A tasteless thing would be something that doesn't seem to show any overall philosophy of design or something which is bombastic - it goes to town on some aspect at the expense of all others - there's a lack of balance. Even then, who cares?

If I wear a bright tomato-coloured suit because I like colour, why should that make me a bad person? It's only when other people have to accept your tastes because they work with you that they're going to moan about them.

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

#78

Post by imiric »

epolanski wrote: post #72
imiric wrote: post #67

Earlier quoted context omitted.

Eh, hard disagree. (Though I didn't downvote you, since it's silly to downvote out of disagreement...) Readability, while subjective, plays a large role in software maintenance. Developers will be more reluctant to change code they don't understand, and more likely to introduce bugs. "Long" functions require following large blocks of code that work within the same context, and relying on comments to explain functiona…

You break up things when it makes sense, not for the sake of it. 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 (same functionality, but higher api surface). You break up things when there are benefits to breaking them and Unix provides a very sensible reference to this topic where plenty of sysca…

> 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 the code does something else, you navigate to that other place (easily done in most IDEs), and change contexts. This context change is important, since humans struggle with keeping track of a lot of it at once. When you have to follow a single long function, the context is polluted with previous functionality, comments, variables, and so on, not unlike the scope of the program at that point. If you're changing the code, it becomes easier to shadow a previous variable, or to change something that subsequent code depends on. Decomposing the large function into smaller ones avoids all of this.

As well as aiding in testability, which you conveniently ignored from my previous comment.

The criteria for determining what is "short" and "long" is subjective, of course, and should be determined by whatever the team collectively agrees on. But there should be some accepted definition of these.

> Stanford professor Jon Ousterhout

Eh, I'm not swayed by arguments from authority. Jon's opinion is as valid as mine or yours.

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

#79

Post by dominicrose »

pyrale wrote: post #76
WalterBright wrote: post #10

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

Obligatory simple made easy. Just because something is simple doesn't mean anyone has the wherewithal to understand it. [1]: https://www.youtube.com/watch?v=SxdOUGdseq4

I loved working in a team that wasn't allowed to use local variables (Rich Hickey decided that Clojure shouldn't have them). The menu of the website was basically implemented as a state machine and it just worked because every possible user interaction was taken into account.

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

#80

Post by t43562 »

OhMeadhbh wrote: post #18

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…

I do understand the feeling. IMO it could be a bit of ageism. I think it's worse when the company (or team) management strategy is to keep everyone feeling insecure and seeing each other as competitors and potential enemies.

I also agree that you sensed the environment and avoided it and were probably right. When looking for a job this can be very dispiriting but then you occasionally do interviews where people are more friendly and secure and it reminds you that it is possible to find a reasonable place.

Post reply on HN