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

81–90 of 245 posts

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

#81

Post by imiric »

t43562 wrote: post #69
imiric wrote: post #45

I like the article. Most engineering decisions are indeed a tradeoff that should be carefully considered. That said... > I will always distrust engineers who justify decisions by saying “it’s best practice”. No engineering decision is “best practice” in all contexts! You have to make the right decision for the specific problem you’re facing. There are indeed general best practices that are applicable to most, if not…

It gets used whenever someone doesn't like something for a reason of personal taste and people who don't really know (like your boss) immediate fixate on it and think "well, we must do that then and why is the other guy (you) suggesting that it doesn't apply in this case? Best practises ALWAYS apply surely? I will have a quiet word with him about standards..." IOW it's a short circuit to not justifying something. If…

Well, sure, but since every decision has tradeoffs, sometimes when arguing for or against a decision, it's easy for managers to side with the person they have more rapport with, who may or may not be correct, rather than decide on technical merits alone.

So, in some cases, it's more beneficial for the company to adopt a "best" practice, than to have engineers engage in arduous discussions, which can cause resentment and further problems within the team.

Needless to say, it's a delicate balance, which is why I wouldn't want to be a manager. :)

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

#82

Post by DavidPiper »

medstrom wrote: post #73
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?

OP may be talking about cargo culting, but it actually just triggered two examples in my mind:

1. Someone who has only ever written code by tutorial, and has no idea of the architecture, performance considerations or usability implications of the code they're writing.

2. Someone who has got to a point in their career LLM Coding and is unable to write code without it because they don't understand what they're doing.

The problem occurs when one of these people:

- Is required to be good at the things they are not yet

- Proceeds as they always have because they are unaware of their skill gap

- (Optionally) gets promoted while things are still _just_ working

IME you hit these silent inflection points as a system begins to scale beyond the experience of the people involved. They survive for a while (Coyote time / the compass is still pointing north) until something happens (the whole thing falls off a cliff / starts to go south).

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

#83

Post by mrkeen »

8-prime wrote: post #52
mrkeen wrote: post #47

"Good taste" is just advice or guidance that you haven't thought through enough to turn into actionable principles. Compare: * I apply the dependency inversion principle to keep my code testable * I minimise the scope and mutability of all my variables With: * These methods do what they say they do * This code is good because it's declarative * These functions have the right number of lines

I may be misunderstanding what you're trying to say, but I feel like this still suffers from one of the mentioned issues - situationality. Even the best actionable principles can be incorrect given a certain set of circumstances. If in those cases you choose to uphold your priciples, rather than choosing what is "right" for the project you would fall into the camp of "bad taste". That is at least how I interpreted th…

> Even the best actionable principles can be incorrect given a certain set of circumstances.

If they are principles, the discussion around whether to apply them can at least be fruitful. "Taste" is bound to devolve into "I like this" vs "I like that".

I don't buy into the "everything has its upsides and its downsides" advice given in the article for the same reason. It's a useless truism. It's a taste:-

I have 1 new feature ticket in my backlog, 3 support tickets, 2 failing tests, and 2 performance regressions. "Premature optimisation is the root of all evil" informs me about the feature work, as does "Make it work, make it right, make it fast". "Reproduce locally" will be my north star for the support, the test failures, and the performance work. Add "Find and measure the bottleneck(s)" for the performance work, as well as "make sure the new code is actually faster than the old code" before checking it in.

I don't need to invoke the maturity of any particular coder for any of this.

Another problem with letting "taste" into the discussion is that you can cheapen principles: you think this code needs tests? "Well, there are upsides and downsides with that", "You're just being inflexible, which is immature". Neither tasteful reply will help you answer whether the code needs tests, and it stirs up shit in the team because it makes it about people, not work, so egos will get inflamed.

>> Personally, I feel like code that uses map and filter looks nicer than using a for loop

I'm not going to argue the person, I'm going to argue the principle. I use map and filter in my business logic because I can do so without mutability. My business logic should reflect the requirements and customer expectations - deterministically. The principle of making the source code pretty is a distant second to the principle of making the code deterministic. If the requirements change from "apply the correct tax rules" to "apply the correct tax rules, if the system is in the right state", then I might well bring in a bunch of mutations to make that happen.

>> is more straightforward to extend to other iteration strategies (like taking two items at a time).

Nope, items.pairs.map((x,y) => ..). Didn't need to discuss maturity.

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

#85

Post by brunorro »

I have bad taste. So I will say suckless.org

- software should do one thing and do it well - code should be understandable, easy to build, easy to port - dependencies should not be a problem - the chosen language must not be a burden - resources are scarce: if you say "unused memory is wasted memory" you are part of the problem

(I know, I'm a horrible person)

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

#86

Post by t43562 »

> 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 like the way it worked. I would start to do so and then, eventually, think that it was going to take ages and be unrecognisable to them. How could I help them by rejecting everything they thought?

I'd think about it again and realise that they weren't idiots - their approach probably could work with a couple of adjustments. I helped them make those adjustments and they were happy because they could understand the result.

After that I would find that my own way of thinking about the problem had changed and my own code would get much better from having seen the problem from a different angle. I should really have been the one thanking them.

I am still like this - still prejudiced - but in the back of my mind I know it and when I'm being sensible I remember to try to give the other viewpoint a proper chance and be happy when it really turns out to have more merit.

Principles are a bit subjective and if you lean on them all the time without thought it's a sort of laziness - you're not really examining the situation and what it merits.

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

#87

Post by PickledChris »

pbalcer wrote: post #59
mojuba wrote: post #20

> 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 impenetrabl…

Readable code is code that has empathy for the reader and tries to minimize the cognitive load of interpreting it. That's one of the goals of abstraction layers and design patterns. Yes, it's all subjective, and depends on the reader's expertise and existing familiarity with the codebase. But arguing that code readability isn't at thing, because it's subjective, is an absurd take. Would you claim that Joyce's Ulysses…

I see this argument pattern a lot, so looked into what the name is. Apparently it's called Sorites paradox: https://en.wikipedia.org/wiki/Sorites_paradox or the "continuum fallacy" in which something that's continuous is dismissed as not existing because we can't divide it into clear categories.

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

#88

Post by t43562 »

imiric wrote: post #81
t43562 wrote: post #69

Earlier quoted context omitted.

It gets used whenever someone doesn't like something for a reason of personal taste and people who don't really know (like your boss) immediate fixate on it and think "well, we must do that then and why is the other guy (you) suggesting that it doesn't apply in this case? Best practises ALWAYS apply surely? I will have a quiet word with him about standards..." IOW it's a short circuit to not justifying something. If…

Well, sure, but since every decision has tradeoffs, sometimes when arguing for or against a decision, it's easy for managers to side with the person they have more rapport with, who may or may not be correct, rather than decide on technical merits alone. So, in some cases, it's more beneficial for the company to adopt a "best" practice, than to have engineers engage in arduous discussions, which can cause resentment…

Oh, you're so right about setting some default standards to prevent arguments!

The most simple and easy one is to auto-format code. That kills so many ridiculous arguments. I wish all problems could solved that simply.

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

#89

Post by epolanski »

imiric wrote: post #78
epolanski wrote: post #72

Earlier quoted context omitted.

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…

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

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

#90

Post by kaffekaka »

PickledChris wrote: post #87
pbalcer wrote: post #59

Earlier quoted context omitted.

Readable code is code that has empathy for the reader and tries to minimize the cognitive load of interpreting it. That's one of the goals of abstraction layers and design patterns. Yes, it's all subjective, and depends on the reader's expertise and existing familiarity with the codebase. But arguing that code readability isn't at thing, because it's subjective, is an absurd take. Would you claim that Joyce's Ulysses…

I see this argument pattern a lot, so looked into what the name is. Apparently it's called Sorites paradox: https://en.wikipedia.org/wiki/Sorites_paradox or the "continuum fallacy" in which something that's continuous is dismissed as not existing because we can't divide it into clear categories.

Did someone claim readability does not exist?
Post reply on HN