Live data from Hacker News

What is “good taste” in software engineering?

seangoedecke.com

131–140 of 245 posts

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

#131
post #59
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…

>> 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 actually have when writing the code - you will thank yourself when you come back to it.

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

#132
Good taste often comes from experience. And not just any experience, either. It comes from working with other peoples' "great ideas" and "brilliant hacks" and "genius architectures". When you're the person having to maintain them a decade later, you start to see whether they were great and brilliant and genius, or just clever but bad ideas. You start to develop a taste that says "that feels too complicated for what it does" or "that's not clear enough". Or, sometimes, "yeah, that really is about as simple as it can be."

It's hard to defend that taste to someone who doesn't have it. They say, "Yeah, well, that's just, like, your opinion, man". And in fact they're right. But it's an opinion honed by a fair amount of real-world experience, of seeing how fine-sounding ideas fail to work out in the long run.

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

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

What a great comment.

Your way of thinking is how I like to handle my direct hires. And people on a project that may not be my direct hires.

Recognize that there are different ways to get things done. Not everything needs to please my specifics, process, etc. if the end result or goal is met

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

#134
>> Languages like Golang don’t contain map and filter at all, for principled reasons.

Go is nice when working with other languages at the same time as there are few language specific things to remember. However, they really should add common things that exist in almost every other language (I'd argue map / filter would be good to have for instance). It isn't really easier if it is "simple" but unique to the language.

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

#135
post #31
post #23

Earlier quoted context omitted.

Theere are two quite a widespread classes of not readable code: Some code is not readable by _anyone_. That's not readable code. Some code is readable by its author only (be it AI or a human). That's also not readable one. Saying readability is not a concept is really strange.

I have a formal proof for you that it is a non-concept. If code can be read and interpreted by a computer, it means it can in principle be read by a human. There are of course some edge cases like obfuscated JavaScript or binary executable that some people are able to read and understand. The question comes down to being reasonably readable and we are back to square one: "reasonable" is very relative. In my early day…

I can't reasonably read whether this comment agrees or disagrees with the parent

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

#136
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!

It's close to the mantra "strong opinions, loosely held", which I appreciate a lot.

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

#137
I don't exactly disagree, but I also don't like how this article confounds concepts and considers the idea that "people value different things" in a bit of a vacuum.

Usually I would expect an engineer to be able to gauge roughly "what values" are most important in a given practical context. Let's call those the "hard constraints" of the problem being solved. Let's set the hard constraints aside and consider "taste" only in the context of the remaining degrees of liberty.

In other words, we often impose on ourselves additional constraints that are not strictly necessary. An artist in a given context may technically be required to use oil paint and a 4x6 canvas. But the work product will be judged on what additional constraints (or lack thereof) the artist plays by.

As a rule of thumb, I'll stick my neck out and say that good software engineering taste, while notionally similar to artistic taste, is unique in that it is 1) aesthetically minimalist, and; 2) maximalist in self-restraint.

I think the notion of taste still eludes this description, but whenever I've encountered something I found truly in bad taste, it usually went counter to these principles for no obvious reason: in other words it was sacrificing something without any benefit. Oftentimes bad taste is taking a loss and calling it a tradeoff: in my experience this often occurs when people confuse simplicity for familiarity.

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

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

"Good taste" I have found comes from experiencing "good" API's and other "good" code. You know good code (and API) when you see it — and in time you should be able to write it as well.

In short though, it's hard to have good coding taste when you are new to the field. (But, as you point out, it's not true that experience guarantees you will acquire taste — you have to both be looking out for it, recognize it, and be able to to mirror it.)

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

#140

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

Exactly. It's occasionally handy if your engineers are capable of doing extraordinary things, but it's even better if they consistently find simple, ordinary solutions to problems that seem formidable at first glance.
Post reply on HN