> no, it should not be fast by default.

Maybe better to elaborate on what it should be, if not fast? Surely you aren’t advocating things should be intentionally slow by default, or carelessly inefficient?

There’s a valid tradeoff between perf and developer time, and it’s fair to want to prioritize developer time. There’s a valid reason to not care about fast if the process is fast enough that a human doesn’t notice.

That said, depends on what your work is, but defaulting to writing faster, more efficient code might benefit a lot of people indirectly. Lower power is valuable for server code and for electricity bills and at some level for air quality in places where power isn’t renewable. Faster benefits parallel processing, it leaves more room for other processes than yours. Faster means companies and users can buy cheaper hardware.

> Maybe better to elaborate on what it should be, if not fast?

It should satisfy the needs of the customer and it should be reasonably secure.

Everything else is a luxury.

My point was that in most of my time in the industry being faster would not have benefited my customers in any manner worth measuring.

I'm not anti-performance. I fantasize about how to make my software faster to maintain my geek credentials. But neither my bosses nor my customers pay for it.

If a customer says they want it faster we'll oblige.

Clean code, easy to maintain is not luxury when talking about a programming language implementation.

Being first to market is usually more important than being faster then those who got there first.

Ha! Good luck convincing end-users that that's true.

Client doesn't care. As long as their advertising spend leads to conversion into your "slow" app, they're happy.