Four prevalent themes in the discussion
-
Premature optimization is often wasteful; optimize after measuring need
“One of the 'evils' of premature optimization is how much time you spend on the optimization vs. the benefit you get from it. If your goal is correctness and shipping fast and you're not memory constrained then spending time using the least amount of memory is a waste of time specifically because you want to ship fast.” – jgrahamc
-
Early focus should be on correctness, performance, and handling load before micro‑optimizing memory
“Having the responses be slow or incorrect is a far more expensive problem. A good engineer would pick a simple data structure that has the right shape but might not be optimal in footprint to focus on correctness and response time.” – sophacles
-
Engineering decisions are shaped by business constraints: limited engineer time, cost, and familiarity with the codebase
“Engineers are expensive, especially good system engineers who are trained in your code base. Very possible that this just hadn't gotten to the top of the priority list.” – gbear605
-
Savings from optimizations become apparent only at large scale; in hindsight they look obvious, but early on the impact was negligible relative to other priorities
“It only looks super obvious in hindsight and the well explained blog post… making that call at that time would've butchered the product very much similar to Google+, YouTube etc.” – suriyaG