No need to stop there - it's just historical, very old advice, the rest is pretty good. It underestimates how aggressively inefficient today's trends and frameworks are. It actually advocates for focusing first on simplicity. And I think Ousterhout would not consider an "easy-to-use" "developer-friendly" but big and featureful framework to be that kind of simplicity. He says:

> "faster" algorithms often have larger constant factors, meaning they are slower at small scale and only become more efficient at large scale

So what I think he's worried about is sophisticated large-scale-oriented algorithms, but that's really not the problem today, which is huge frameworks and middleware and cluster applications, and the desire to use the very latest of these things. More than once I've heard a frontend dev say they want to use "react and redux" for the next project, without knowing what redux is. I've also seen many backend teams decide they need to use Cassandra for scalability and availability, but the cluster ends up being overwhelmed or down for half a day, every month or so, because you need to be a JVM and Cassandra expert to keep those clusters working. I think this kind of thing is exactly what Ousterhout would warn against.

The zeitgeist has swung wildly in the other direction, developers are no longer eager to implement the most complicated algorithm for theoretical optimization, now they are eager to implement the most complicated frameworks and services for "best practices and to be more maintainable" than the last mess they made. But the recommendation is the same in both cases: make it simple. Study the problem, clean up the mess (hard work!), keep it simple.

> use Cassandra for scalability and availability, but the cluster ends up being overwhelmed or down for half a day, every month or so, because you need to be a JVM and Cassandra expert to keep those clusters working.

Phew.. it's not just me. My one exposure to Cassandra [1] in a production environment mirrors this experience very closely. I felt a bit like the child in the tale looking at the nude Emperor.

Each node held only a single SSD, so increasing database size meant buying an additional multi-thousand-dollar server. Upgrading RAM meant upgrading all the nodes, which became an O(number of nodes) problem in terms of time and cost.

The backend team may have had a JVM expert or two, but obviously no Cassandra (nor database in general, and certainly not hardware) knowledge. It was the Ops team who had to keep it limping along and gain the expertise.

It's just another case of "it works for FAANG, so it'll work for us" thinking, even though "us" is 2-3 OOM smaller and would be better served by the simplicity of a scaled "up" non-distributed system.

[1] Also plenty of experiences with non-Cassandra distributed (usually "NoSQL") databases. The results have ranged from grossly over-engineered (i.e. high cost) to unreliable and/or high-maintenance. Fortunately, rarely both at the same time.

The problem is not this advice, but that people tend to stop reading (or remembering) there. It's misapplied or misunderstood so often that I wonder if it shouldn't be promulgated. Today something like this may be more appropriate:

"You should pay attention to performance, but your algorithms probably won't be the problem. It's more likely you're doing something stupid or wasteful, probably with the help of your technology stack."

>The problem is not this advice, but that people tend to stop reading (or remembering) there. It's misapplied or misunderstood so often that I wonder if it shouldn't be promulgated.

That's EXACTLY my problem whenever I hear this or similar advice. It's exactly what I think when I hear people (mis)quote Knuth by mindlessly parroting the old adage (optimization is the root of all evil). Too many people interpret this as a licence to waste resources and bloat your program with reckless abandon to an egregious degree, that I too think people should probably not say spread stuff like this.

In case you didn't know the author has built the programming language that formed the backbone of some of the original multithreaded web servers that reached an incredible scale for their time. He is currently involved in research on "core aware thread management", "nanosecond-scale logging".

This causes me to interpret statements like "Programmers tend to worry too much and too soon about performance." more charitably. I think he does care about real performance.

> too much and too soon

That's the critical part of that statement. It is not important to solve for performance concerns until the code actually works so you can verify you've solved the problem at hand.

why do people post this kind of stuff "stopped reading right ....". congrats now we all know you're too arrogant and too impatient to finish a 1000 word essay. don't you realize that dismissing the bulk of the text based on just one comment is ignorant? do you think it matters to anyone what you even think relative to this person? do you think you have some deep insight that others don't (such that they don't already realize that that particular point should be contextualized appropriately). I just don't understand people constantly trying to assert their delusional superiority at every vague opportunity - let me kindly inform you that op posting this wasn't an invitation.

Worth noting that probabilistic reasoning via approximations are actually pretty cool. Its just that the same sort of thing that makes them great is also a thing which makes them terrible. The upside of not being thorough is being fast and the downside in being fast is not being through.

I find it neat that the person arguing for speed is employing heuristics which short circuit reading.

A great way to look at human biases is through the lens of the good they cause. It makes them all make sense in a way that looking at them through the lens of failure cases doesn't. The world is awe inspiring in its complexity and coping with that efficiently and in real time requires trade offs. Catch the same person who appears delusional in one real-time context at a time wherein they can think for longer and their thinking can become much more logical and mathematical.

It was hyperbole. I did actually read the rest of the points, I just didn't pay any more attention to that one.

I don't feel any kind of superiority, I was just voicing my opinion. Maybe you're projecting?

Performance _or_ resource conservation. Which one is it?

Application design and domain knowledge are more important than rote optimization. I think that is what Ousterhout is getting at.

I agree with you. I've worked on drivers for virtual NICs. Every performance boost was well received by customers