As a developer you should 1) have the fastest possible code / test cycle - i.e. it's worth overpaying for faster machines 2) treat performance as a feature and formally measure it across configurations
I've worked for many companies, small and large, corporate and startups. None of them had performance as a priority, or even considered at the product level. Any minimal performance optimization or win we had was because a developer cared enough for it.... but maybe I'm the only one and just had bad luck with the product managers/owners I had.
The only companies I have worked for that really cared for performance were betting companies, because speed is money in that sector (esp. in live betting).
I have seen the same basic cycle, management says don't focus on perf, just "knock out" (I despise this lingo) the features. They have this overconfidence, but flop on the next release and patronize the dev team about perf.
1) tracked from the beginning so it is drained from the system merge by merge
2) architected in at the design level and not applied as a spell.
I really like what the rust team is doing with tracking rustc compilation times. Another reason that integration tests are the best tests.
We definitely promote performance as a primary (and a half) concern. Mainly because the alternative is throwing more money at servers and/or dealing with disgruntled customers. I wish we dedicated more resources to it but we also don't ignore it.
Oh! yes... certainly that was mi experience too. I was referring to frontend... where you won't pay for the performance, but your users will (by having to upgrade their compures and/or just suffering it)
