[maccard]

> Stop worrying about how well your code performs and focus on more important things.

It's very naive to think that that's an acceptable tradeoff in every situation. Would you accept it if chrome/FF/<browser of choice> suddenly consumed an extra 30% of memory and CPU time after a single update, because the developers decided that the HTML rendering code wasn't readable enough? Or if you're writing code for cars that needs a response time in sub millisecond ranges to delay for hundreds of milliseconds before engaging traction control because the code wasn't well labelled, so it was rewritten?

There are plenty of cases where performance is absolutely critical, and it is the most important thing.

[fat0wl]

yep there are also a lot of situations in enterprise where you don't exactly know how your code will be used in near future (in <5 years it could grow to exponentially more customers using it compared to soft releases to select test customers).

Because of that I'd say.... it's not like I see a lot of people get raked over the coals for it, but there is definitely some organizational disappointment when a silly scaling bug crops up in production[1]. I think as a mature dev it is proper to internalize as many performance-related techniques as possible so that you can write more performant code with each subsequent project. Sometimes it doesn't even affect the amount of initial coding hours, it is just one of the freebie gains that comes with experience.

[1] Many more such bugs would probably occur if the company didn't occasionally get around to load-testing, so that should be part of CI or dev cycle if possible.