Good taste is writing code that looks so simple, everyone else says "pshaw, anyone could have written that!"
Sometimes, simple code is viewed as an invitation to make it more complicated.
What is “good taste” in software engineering?
201–210 of 245 posts
Re: What is “good taste” in software engineering?
#202Earlier quoted context omitted.
> everyone else says "pshaw, anyone could have written that!" it really depends on the problem domain tho, doesnt it? Would you call the fast inverse square root[0] code good taste? [0] https://en.wikipedia.org/wiki/Fast_inverse_square_root#Overv...
Being a good fit for a given purpose doesn't mean that something is in good taste. That piece of code is very performant, yes, but I'm pretty sure none of us would want to meet it in code review, save for a few niche edge cases. To draw a parallel from fashion, for most part, arctic snow gear does not win fashion prizes, but it does keep you alive. There's a time and place for both, doesn't mean that everything usefu…
What is "most" here? Traditional Arctic clothing (e.g. Inuit clothing) has huge fashion aspects. Being able to look good and stay comfortable in a blizzard are both important to many people in the far north.
I highly recommend checking out the clothing and fur stores to accessorize if you're in an Inuit town with nothing but "purely practical" Western clothing. A fashionable design will improve both the look and the cold weather performance.
This sometimes gets taken to the extremes of high fashion, like this design by an Inuit woman:
https://vafashion.ca/pages/the-ukiaksaq-collection-nyfw-2020
Re: What is “good taste” in software engineering?
#203Good taste is writing code that looks so simple, everyone else says "pshaw, anyone could have written that!"
I have another example. I have a '72 Dodge Challenger. I've taken the thing apart, and put it back together. I never cease to be surprised at how well-engineered it is in its simple, direct, and inexpensive solutions to making an amazing car. For example, consider the instruments. They run off of 5 volts, while the system voltage of the car is anywhere from 10-18 volts. How to get 5 volts? It has a sort of buzzer whi…
I don't know that I'd describe this as "good". It's a hack solution that mostly worked at the time.
Those mechanical voltage regulators wore out and had to be replaced periodically. They weren't great at maintaining consistent voltage so consumers had to accept loose voltage tolerances. They made noise and generated electrical interference.
Modern cars are more reliable, despite their complexity. I'll take solid state.
Re: What is “good taste” in software engineering?
#204Good taste is writing code that looks so simple, everyone else says "pshaw, anyone could have written that!"
> everyone else says "pshaw, anyone could have written that!" it really depends on the problem domain tho, doesnt it? Would you call the fast inverse square root[0] code good taste? [0] https://en.wikipedia.org/wiki/Fast_inverse_square_root#Overv...
Yes, but the "good taste" part lies mainly in three things: 1) recognizing that a reciprocal square root is more useful than an actual square root (and likely cheaper), 2) recognizing that full precision isn't necessary, 3) recognizing that one (or two) Newton-Raphson iterations is good enough with a decent starting approximation.
The starting approximation is just magic.
Re: What is “good taste” in software engineering?
#205Earlier quoted context omitted.
If you are breaking something up for "long" and "short" you're optimizing for the wrong thing. You don't care about code being short for its own sake or long for its own sake right? Ultimately, you're going to revisit this code to make the change after some time passes. Is it easy to follow the code and make the change without making mistakes? Is it easy for someone else on the team to do the same? Sometimes optimizi…
> If you are breaking something up for "long" and "short" you're optimizing for the wrong thing. You don't care about code being short for its own sake or long for its own sake right? You're misunderstanding. Code is not broken up because it's "long". It's broken up because it is difficult to comprehend and maintain, and its length is one criterion that might signal that to be the case. Another sign is cyclomatic com…
> and its length is one criterion that might signal that to be the case
You seem to be the one misunderstand it.
It's just not. Function length is not a useful metric, at all. The probability of some problems increase with length, but even then it's not the length that will tell you if your code has a problem or not.
If you have length guidelines, your guidelines are bad.
And, yeah, cyclomatic complexity is almost as useless as function length. If you have warnings bothering people about those, you are reducing your code quality.
Re: What is “good taste” in software engineering?
#206Earlier quoted context omitted.
I'd argue the opposite, and go further and say there is no "good" code, only "not bad" code. I feel like most of what I think is good is because it's the only remaining option left after removing the "bad" ones. It's also way easier to find out why something is "bad" vs why something is "good" for some reason, not sure why. In the end, all code comes with tradeoffs, so I'm guessing we're really talking about good/bad…
I describe this as the Artist vs Scientist software engineer. I’m also an “artist” and approach the problem as a ball of clay, hacking away at it (and sometimes starting with a new ball) until the solution appears beneath my hands. The Scientist approach is to know the solution ahead of time , write tests to ensure it comes out the expected way, and then execute.
In writing they call this the "gardener" (artist) vs "architect" (scientist). Some writers plot more at the beginning, and others just dive straight into writing, knowing that they'll have plenty of revising ahead of them.
I'm definitely more of a gardener myself, and I've always considered the architect software engineers of the world to be silly and unfun and prone to locking themselves into an over-engineered architecture before they even understood the problem properly, but they really are just different approaches to software development and each of them has their strengths.
In indie game development, the requirements are often unclear, and I am still exploring what the game idea might be, still trying to "find the fun" of a game, and so the gardening approach works quite well.
In other fields, where you have clear requirements figured out from day one and the consequences for not meeting those requirements is much higher, the architect's approach has its wisdom.
Re: What is “good taste” in software engineering?
#207Tabs instead of spaces.
One user is able to fit more code into LLM context window since tabs take one token and spaces take 4. https://old.reddit.com/r/ChatGPTCoding/comments/15s62yl/save...
Did these systems really not learn to recognize a run of four spaces as a single token, despite all the Python source code fed to them?
Re: What is “good taste” in software engineering?
#208> 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.
To add to this, there are fundamental information-theoretic principles that support inlining code and components. It's about reducing code entropy, reducing length and referential distances. https://benoitessiambre.com/entropy.html
The good thing is LLMs try to optimize for information theoretic measures of language so they naturally generate better scoped more inline code. LLMs might help us win this battle :-)
Re: What is “good taste” in software engineering?
#209I’d suggest reading Hammond’s, The Art of Doing Science and Engineering . He literally ran a course to help people develop, “taste.”
For others trying to find this, the author's name appears to be Richard W. Hamming.[0] [1]
[0] Of Hamming distance fame
[1] Here's a link to the Wikipedia article about the book: https://en.wikipedia.org/wiki/The_Art_of_Doing_Science_and_E...
Re: What is “good taste” in software engineering?
#210> 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…
> Readability is a non-concept really. Maxwell's famous equations are readable to some and absolutely impenetrable to the rest of us.
When we talk about a language's readability we're typically talking about 'accidental complexity', to use Brooks' term, [0] and not the 'essential complexity' of the problem being solved. For a hairy enough algorithm, even pseudocode can be difficult to understand.
Readability applies in mathematics too, as a bad notation may make formulae unnecessarily difficult to comprehend.
> So when someone says "code should be readable", to whom exactly?
I'll have a go: to another competent engineer familiar with the general problem domain but not familiar with your specific work. This includes yourself in 2 years time.
This seems rather like the question of readability for scientific writing. Research papers should be readable to other researchers in the field, but they aren't generally expected to be readable to a general audience.