Oddbean new post about | logout
 https://types.pl/@graydon/111144025966056604 makes me wonder, what other engineering truisms are overrated?

A related one that I often heard in contexts where it was wildly wrong was "engineer time is more expensive than CPU time", e.g., I would sometimes hear this from staff engineers at Twitter, but if you just looked at hardware TCO compared to eng compensation, they were roughly comparable and, at the margin, you could probably cut costs by 90% (WAG) if you seriously spent 10% of eng time on cost cutting.

https://files.mastodon.social/media_attachments/files/111/147/707/084/406/260/original/137181d6b824ae33.png 
 @ed709062 "good code is self-documenting" 
 Another, discussed in https://danluu.com/nothing-works/, is the oft-repeated statement that you should focus on "core competencies" which, commonly used to justify buying a SaaS solution from some startup (which then, if you're lucky, and the company doesn't fold, often turns into buying something from  Private Equity/Cisco/Salesforce/etc.).

Also, saying comments get out of date / code is self-documenting  to justify not writing comments (thx https://mastodon.social/@asmodai/111147721770157534). 
 @ed709062 maybe this one has been beaten to death, but: "premature optimization, yadda yadda yadda" 
 @ed709062 In my experience, "minimum viable product" is always misused to describe a 1.0 feature set. Nobody wants to put their brand on version 0.1 
 @ed709062 

Most of these idioms have a kernel of truth to them but if you hyperfocus on the literal or metric implication it becomes an example of https://en.wikipedia.org/wiki/Goodhart's_law

"engineer time is more expensive than CPU time" => https://xkcd.com/1205/

"good code is self-documenting" should encourage well-named methods and variables.

But all of these can be taken to an extreme, saying no comments or don't optimize or strictly following a pattern, without understanding why.

https://en.wikipedia.org/wiki/Don%27t_throw_the_baby_out_with_the_bathwater 
 @ed709062 most time spent and suffering in the whole career is on reading others people's code and understanding what it does, making careful changes to disrupt as little as possible of what already exists so things don't break. Very very rarely does it matter the speed or quality of how it's written. At the end of the day most time is spent understanding the weirdness of the codebase and reviewing PRs.

So yeah, code for reading should be a maximised ideal.