Stopped reading there. A great plague of modern software development is a complete disregard for performance or resource conservation.
> "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.
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.
"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."
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.
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.
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.
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.
I don't feel any kind of superiority, I was just voicing my opinion. Maybe you're projecting?
Application design and domain knowledge are more important than rote optimization. I think that is what Ousterhout is getting at.