"Premature optimization is the root of all evil."
Donald Knuth wrote that in 1974. It is one of the most cited lines in all of software engineerin...
For further actions, you may consider blocking this person and/or reporting abuse
This is a really good point and something that gets misunderstood a lot.
I’ve also seen the “premature optimization” quote used as an excuse for things that are clearly inefficient by design. There’s a big difference between micro-optimizing something early and simply avoiding obvious waste.
While working on a small personal blog project recently I ran into a similar situation when experimenting with rich-text editors. Some solutions made development faster at first, but they also introduced complexity and performance trade-offs that became obvious once the project started growing.
That experience made me appreciate the idea of “basic engineering competence” you mentioned here — understanding what the code and the tools actually do under the hood.
In your experience, do you think modern frameworks make this problem worse by hiding too much complexity from developers?
The distinction you're drawing is exactly right: lazy patterns aren't optimizations, they're just not thinking. But the deeper problem isn't technical, it's that slow code ships because the person writing it never has to wait for it. Localhost with 50 rows feels fast. Production with 50,000 users does not. The feedback loop is broken.
The N+1 example is spot on, but I'd push back slightly on eager loading as the default fix — in systems with deep relationship graphs, it can quietly balloon memory usage worse than the query count it solves. Profiling both sides matters.
yup totally, eager loading can get hairy with deep relationships, memory can blow up fast. Still, N+1s are basically free points lost by default 😅.
Profiling both ways do matter.
*Honestly the N+1 query part hit a bit too close *
I’ve seen (and written) code exactly like that early on, where it looks clean in the loop but you forget every iteration is another database call. On localhost with like 20 rows everything feels instant, so nobody notices. Then later with real data it suddenly becomes “why is this endpoint 400-500ms??”.
I like how you framed it as competence vs optimization. Using a JOIN instead of 200 queries isn’t really “optimizing”, it’s just… using the database the way it was meant to be used.
Also the point about frameworks making this easy is real. ORMs and resolvers kinda hide what’s happening underneath, so it’s easy to accidentally create these patterns without realizing it.
At some point in your career, you will need to accept that, in each project, you should start small and simple and will have to refactor a couple of times as you progress.
preach. it never fails to amaze me that some people don't like the fact that code will eventually need to be refactored.
I know a lot of people that suffer from Premature Optimization
haha yes, it’s like a rite of passage for devs. all of that just save a few microseconds
the Knuth quote has been doing so much damage for so long. i have seen developers use it to justify N+1 queries, loading entire tables into memory, and rebuilding indexes on every request - all with a straight face. "dont optimize prematurely" got twisted into "never think about performance until users are screaming". there is a middle ground between micro-optimizing string concatenation and just... writing code that is not obviously broken
Avoiding premature optimization is no a matter of "lazyness", it is about maintainability and cost.
There are situations where performance comes directly from applying best practices and judgement (like the countries example). Totally agree with you here.
But there are many situations where we try to optimize for a situation that we don't know if will happen. In theses cases I prefer to optimize when the code becomes really a bottleneck.