Live data from Hacker News

What is “good taste” in software engineering?

seangoedecke.com

231–240 of 245 posts

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

#231

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)

Are you quoting suckless.org? Or paraphrasing? In a skim, I see some philosophy stuff there but not exactly this. I think those are platitudes: they sound good but aren't specific enough that anyone disagrees with them, so they're not saying anything. Imagine: > - software should do one thing and do it well No one ever says "let's do a bit of everything, badly". And there's tons of wiggle room in "one thing". Imagine…

About doing one thing and doing it well, the best (anti) example is systemd. I think that having a DNS resolver and mounting your partitions should be two totally separated things. Fortunately nobody uses syste... Oh, wait!

About the code should be understandable and the efficiency, I'm thinking of the old times java. I've seen people in systems department having to profile java stuff because they were OOMing their tomcats. Eventually we had to ask for the code, debug it and send it patched with just some '=null' because the GC wasn't doing its job in the best way. In the early 2000 the philosophy already was "Good hardware is cheaper than expert developers" :(

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

#232

Bad Taste Leads to X; We're trying to avoid X. To me, it is closely aligned to predicting the future of a code base. So really, good taste is about navigating future uncertainty by laying down foundational elements that protect against the uncertainty so you don't drive off a cliff.

> So really, good taste is about navigating future uncertainty by laying down foundational elements that protect against the uncertainty so you don't drive off a cliff.

Absolutely! But also be careful not to over-engineer a solution for a situation that never appeared

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

#233
post #112

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)

It's not wrong per-se, but they practice it to a level of extreme that it seems more like a principled art piece than usable software. Software engineering is all about knowing your project-specific constraints, it should not be wasteful - and that goes for runtime performance / memory usage as much as the time invested. Usability is another factor - suckless software is very inaccessible to people who don't know how…

Holy sh... I didn't expect that Godwin's law would apply that quickly. IMHO, I'm also part of the problem and I think I am a horrible person, but at least I don't consider myself superior to anyone in any way no matter their race, gender, software philosophy or their political views as far as they don't fall in the tolerance paradox.

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

#234
post #112

Earlier quoted context omitted.

It's not wrong per-se, but they practice it to a level of extreme that it seems more like a principled art piece than usable software. Software engineering is all about knowing your project-specific constraints, it should not be wasteful - and that goes for runtime performance / memory usage as much as the time invested. Usability is another factor - suckless software is very inaccessible to people who don't know how…

Holy sh... I didn't expect that Godwin's law would apply that quickly. IMHO, I'm also part of the problem and I think I am a horrible person, but at least I don't consider myself superior to anyone in any way no matter their race, gender, software philosophy or their political views as far as they don't fall in the tolerance paradox.

It's pretty well documented that they called their mailserver "Wolfsschanze" (which was one of Hitler's military bunkers). Whether or not that's just edgy behavior or not, I don't know, but my guess it's a bit of both considering suckless people have complained about "cultural marxism", which is a term with pretty straight lineage to the Nazi's "cultural bolshevism".

So... is that not a nazi reference? Why else would you preempt being "horrible".

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

#235
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…

>> 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. Usually that means something less than "perfect" from the perspective of the writer. Applying to much DRY, SOLID, DI and other "best practices" will make it very hard to understand. Pretend you have about 20 less IQ points than you act…

Reminds me of someone's quote:

> Reading -- and understanding -- code requires twice the brainpower of writing code. So if you used every bit of your intelligence to write 'clever' code, you won't be able to maintain it because it requires twice your intelligence to read it again.

Einstein's words are oh so suitable as well:

> Everything should be made as simple as possible, but not simpler.

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

#236

Earlier quoted context omitted.

I don't ever tall a junior that they are doing something in a less-than-optimal way. I always ask them why they're doing it that way. At the end of each conversation, one of us has learned something. Sometimes I learn an alternate approach, and sometimes they learn why their alternate approach won't work in the long run. Either way, it's never a confrontational conversation.

Asking questions is always the best way to correct someone (Hey Socrates). You avoid triggering defense, and if it turns out you were wrong, you don’t sound like a jackass.

This is why I never went into CS educationally. I was never treated in a respectful way by the Polish system. Always treated like ass

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

#237

Earlier quoted context omitted.

Are you quoting suckless.org? Or paraphrasing? In a skim, I see some philosophy stuff there but not exactly this. I think those are platitudes: they sound good but aren't specific enough that anyone disagrees with them, so they're not saying anything. Imagine: > - software should do one thing and do it well No one ever says "let's do a bit of everything, badly". And there's tons of wiggle room in "one thing". Imagine…

About doing one thing and doing it well, the best (anti) example is systemd. I think that having a DNS resolver and mounting your partitions should be two totally separated things. Fortunately nobody uses syste... Oh, wait! About the code should be understandable and the efficiency, I'm thinking of the old times java. I've seen people in systems department having to profile java stuff because they were OOMing their t…

> About doing one thing and doing it well, the best (anti) example is systemd. I think that having a DNS resolver and mounting your partitions should be two totally separated things. Fortunately nobody uses syste... Oh, wait!

People have asked the systemd folks about this, and their answer is that these are separate things because systemd-resolver is a distinct, optional binary that does one thing well. Is that enough to say they're totally separate things? Opinions obviously differ!

It is really hard to come up with rules of taste that are generally applicable yet specific enough to that people interpret them in the same way to make the same decisions. I don't really have any such rules of my own to offer. I've written coding standards for multiple projects but I definitely can't copy'n'paste one to another and have it still make sense.

> About the code should be understandable and the efficiency, I'm thinking of the old times java. I've seen people in systems department having to profile java stuff because they were OOMing their tomcats. Eventually we had to ask for the code, debug it and send it patched with just some '=null' because the GC wasn't doing its job in the best way. In the early 2000 the philosophy already was "Good hardware is cheaper than expert developers" :(

Yeah, there are plenty of examples of poorly written applications around. [1] But I don't think someone said "let's write this code really badly and just buy bigger machines". Could be wrong, just never heard anyone say that. On the other hand, I do almost universally see people prioritize the next "critical" feature over clearing the bug tracker. So if you said for example "fixing customer-reported memory leaks always takes priority over new features" that'd be making a real, controversial taste choice.

[1] ...and my guess is this was a poorly written application—keeping around reachable references too long, thus forbidding GC from cleaning them up, rather than a flawed Java GC algorithm that didn't detect the parent was also unreachable in a timely way.

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

#238
post #232

Bad Taste Leads to X; We're trying to avoid X. To me, it is closely aligned to predicting the future of a code base. So really, good taste is about navigating future uncertainty by laying down foundational elements that protect against the uncertainty so you don't drive off a cliff.

> So really, good taste is about navigating future uncertainty by laying down foundational elements that protect against the uncertainty so you don't drive off a cliff. Absolutely! But also be careful not to over-engineer a solution for a situation that never appeared

You can never predict with 100% certainty, unless you're building a clone.

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

#240

Earlier quoted context omitted.

I don't think code is inherently bad or good without defining the exact context and purpose of the code. It all depends on what field you are in, the business requirements, the team and so many other factors. What is the most important aspect: Easy to extend, easy to read or most optimal performance? Is your team more comfortable with the functional style of programming or OO? Do you follow existing conventions your…

> Do you write code that makes you look smart using tech that looks good on your resume > The is no one right way to program. Those two statements taken together makes me suspect you think there is.

I do. I am not free of an ego. I just try to not confuse my taste for objective good or wrong though I sometimes fail.
Post reply on HN