I'm saying there are very few real black and whites, and everything in life and in software is more kind of grey.

As such there are very few black and white rules you can follow and succeed.

The correct approach is somewhere to the left of "premature optimization" and somewhere to the right of "don't even think about performance until you can measure it".

More experienced and talented people will be more successful at picking that sweet spot.

Telling a dev that the correct approach is to pay absolutely no attention to performance before it can be measured is ... crazy IMO. I would expect them to have at least thought about it, and have some opinions, just as they should not have put excessive effort into prematurely optimizing things they don't know are going to be a problem.

My point is - its grey, use your brains, don't buy into absolute rules.

Agree with you fully. People take these blanket generalizations and make them rules and then use them to ignorantly judge someone's decisions. I've worked on projects where performance needed to be addressed up front or else it just wasn't viable.

I think GP is saying, if you are at a point in development where you can choose A or B, and A has foreseeable better performance or scalability, all else being equal choose A.

A lot of assumptions there and real world is almost never that clear-cut.

The general advice of "don't optimize until you've measured" is still almost always correct.

> The general advice of "don't optimize until you've measured" is still almost always correct.

The issue of course being that when designing code, various design choices can have significant performance implications, and can be very hard to change once implemented and in production.