There is a 'pre' in 'pre-mature' for a reason. If you don't seek to optimize even when it is 'mature', you are not a good software engineer. In this story, ins

There is a 'pre' in 'pre-mature' for a reason. If you don't seek to optimize even when it is 'mature', you are not a good software engineer. In this story, instead of doing meetings, why did no one fire up the profiler and actually try to figure out why the heap size was so big? If the senior architect's first thought is to come up with an elaborate proposal even before they understand the memory and processing budgets of their program, what are they a senior architect for? It's like trying to shave off micro seconds of processing time while your network call takes milliseconds. Good style guides strike the balance where common caveats and easy to miss gotchas are avoided by making rules around them (and then it's no longer premature optimization because someone already did the math and decided on the optimization, so each new programmer using it is not optimizing but merely following a rule in the style guide), while leaving the complex cases for the programmer to optimize as and when needed. Many people who scoff at opinionated style guides forget that in a big company you don't want 1000 engineers to spend time independently figuring out whether X needs to be optimized [1]. If someone can do the profiling, figure out what should be done in 99% of cases, make a style rule out of it explaining the rationale, it saves everyone the hassle. I believe Google does exactly this. [1] Apart from the waste of time, not every engineer might be capable of actually figuring it out. Many of the intricacies of C++ for example aren't immediately obvious even if you have spent years with the language. It's more optimal to hire a few C++ super-experts, have them do the profiling, and come up with style guidance.