41–50 of 245 posts
Good taste is writing code that looks so simple, 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...
Those who have a good taste can distinguish a good taste from a bad taste. Those who don't have a good taste can not.
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.
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…
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. Bash, Linux, etc.
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 all, situations. E.g. version control and testing (arguably even the testing approach) are practices that every competent developer would agree are pretty much requirements.
Context does matter, but within specific contexts there are practices that can be generally considered "best", because applying them delivers more value than not, and their drawbacks are manageable.
For example, after a certain team size, implementing a CI pipeline is a best practice. Yes, it takes time and effort to implement and maintain, but the benefits far outweigh the drawbacks. After a certain scale, implementing a robust and efficient infrastructure management and deployment solution is pretty much a requirement. Relying on ClickOps to provision infrastructure, and deploying with shell scripts over SSH, while technically "simple", can only get you so far. And so on.
These practices become more evident with experience, and deciding when to vouch for them, even strongly, becomes more evident with wisdom. So I wouldn't necessarilly always distrust engineers who want to promote best practices. I would listen to them, discuss it with them, and make a decision along with the rest of the team. If they do push back after a decision has been made, that would be a bigger issue. Not necessarilly with that specific engineer―it could also be a sign of communication problems, egos, politics, etc. Unfortunately, there are many dysfunctional teams and companies with toxic environments, but I suppose that's just human nature.
> 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…
If the new engineer is well versed in mapping and filtering he/she'll have an easier time onboarding a codebase that's rather void of manual loops.
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
> 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…
Good 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...