Wikipedia has the quotes: https://en.wikipedia.org/wiki/Program_optimization#When_to_optimize https://en.wikipedia.org/wiki/Program_optimization#When_to_o... W

Wikipedia has the quotes: https://en.wikipedia.org/wiki/Program_optimization#When_to_optimize https://en.wikipedia.org/wiki/Program_optimization#When_to_o... We shouldn't reinvent a phrase. Premature optimization has always been about programming efficiently, ie. a newbie programmer or even expert "elite" programmer could easily fall into the trap of optimizing prematurely. That means: Spending too much time on very little gain performance-wise, thinking it's important to eke out every little drop of performance. It's a programming lesson only. Experience even show that premature unproven tweaks can both reduce performance and make code harder to read and maintain. Then there's the business lesson: Since for the last decades we've had Moore's Law and then more, it's been very hard to make the effort pay off by programming for performance. So businesses have learnt to focus on reducing programming time. Coincidentally, it's been shown that quick lead times are beneficial in the competitive marketplace as well. This is a business lesson (not about the programming phrase "premature optimization"!). We're seeing a reintroduction of optimization and performance, because meeting a ceiling in CPU cycles and the need to utilize more cores efficiently. So we have Golang, Rust, WebAssembly, etc. Having a snappy website and not annoy your users will pay off as well (hello there multiple choice agreement-notices!). But the programming lesson still stands: For many types of workloads, it doesn't make sense to spend too much time optimizing, performance wise, unless you see proven benefit outweighing the costs. In most cases, it's actually better to optimize afterwards (ie. prototyping and iterating), unless one has a specific algorithm or solution in mind beforehand. The business lesson is similar, with the added twist of being a criteria wether you make it or break it. For programming, you could just do it for fun or a hobby, and can premature optimize to your hearts content if you like. But it'll be harder now to fall into that trap instead of making something more worthwhile! ;-)