May not be very popular of an opinion, but rule #1&2 have been used as a crutch to create bloatware and slow as dogshit software that is always dismissed under a guise of someone is going to find the time to retroactively implement some tracing and introspection system and then rewrite portions of the application in magically isolated interfaces that will make the slow POC fast. It very rarely happens and is usually in the form of a complete rewrite that is forced onto a short timeline so.... you can't possibly be so new as to prematurely optimize! (just rewrite it in a new stack it will solve it somehow)
*edit to offer something less whiney
I think optimizations that rely on specific non-core business rules are a root of evil - but you should still be properly indexing your queries, not doing them in loops, trying to make parallel work run in parallel, not write a ton of junk over the wire when ever you can, be conscious of nesting any loops and generally the best optimization is even listed: choosing the correct data types for a problem.
> you should still be properly indexing your queries, not doing them in loops, trying to make parallel work run in parallel, not write a ton of junk over the wire when ever you can, be conscious of nesting any loops and generally the best optimization is even listed: choosing the correct data types for a problem.
I don't think anyone disagrees with that, but the indexing is a good example of "measure, don't assume" because SQL engines can do surprising things, and the best way to know what to index is just to measure (and sometimes no index is actually best!)
And "completely pretend performance is not a thing" is of course the other extreme from "optimise everything from the get go".
Unfortunately there are always people who these sort of "rules", "laws", and "best practices" as cudgels to beat other arguments with, rather than some loose commentary (which is usually what it is). Previous comment: https://news.ycombinator.com/item?id=36417264
*edit to offer something less whiney I think optimizations that rely on specific non-core business rules are a root of evil - but you should still be properly indexing your queries, not doing them in loops, trying to make parallel work run in parallel, not write a ton of junk over the wire when ever you can, be conscious of nesting any loops and generally the best optimization is even listed: choosing the correct data types for a problem.