There was another, much older, post similar to this about, I think, "beans" that engineers use to solve problems. If I remember correctly, it was something like, solving a problem costs "beans", and engineers will always use most all of their "beans" to solve a given problem, because it's somewhat "easy" until you run out of them.
Maybe it wasn't beans? But, I've been looking for it for years.
His example of a web crawler stinks. I can get behind the philosophy, but his specific web crawler example at a minimum needs to retry, respect robots.txt, and rate limit per domain. So no, xargs + curl is a dumb example.
Replace curl with wget, get robots.txt support. Write timed-out URLs into a file for the next identical run.
The idea stays: you can jerry-rig a web crawler from pedestrian, readily available parts, and quickly test the idea for which you wanted to crawl the Web.
The point is that bash, xargs, wget, make, etc are well-understood, well-maintained tools. They are not even necessarily simple, but they likely contain very few unknown unknowns.
Based on bot traffic to my personal blog over the past year or so, the minimum viable web crawler apparently does not need any of those things (much to my own personal annoyance, to be very clear).
I’m vaguely recalling something - and I think the beans might’ve also represented vetos, so one had a limited number of objections to other people’s ideas… quick search revealing nothing so far, though.
This is where efficiency can be applied in two distinct ways. On the one hand, if using more beans means you can solve the problem more quickly, then it is more efficient to the problem solver to do so.
But if beans are scarce, and that's where you can try to find ways to use less beans per function, then the goal is to make the function more efficient by using less beans.
Maybe it wasn't beans? But, I've been looking for it for years.