As someone else said, businesses hire software engineers to solve business problems. Speed often isn't a priority. Fast software will make the experience perceivably better, but it's hard to get on a sales call and tell a potential customer that your application loads much faster when they are looking for feature X. And most companies buying software are looking at a checklist of features first and then maybe the experience.
You also need to put in the time to make software fast and then keep it fast. It's not something you can tack on at the end—if you want something to be fast, that has to be carefully considered from the very beginning. By the time people notice something is too slow, you're burdened by half baked architecture and a monstrosity of a codebase. At that point, it's near impossible to really make anything fast.
I think the hugely successful SalesForce proves this point. Just one standout among many such products.
If the market values fast software, you'll see a lot more fast software. There _is_ a lot of unnecessarily slow software these days, so it _is_ starting to happen. Think Superhuman, Linear.app, etc. — an entire category of software based primarily on the idea of being fast, aimed at the power user. If these apps succeed, you'll see a lot more of them. If the market doesn't value fast software, most commercial software will be slow.
I don't think companies choose to make bad software as a tradeoff. Salesforce had enough budget to build out those features and not be terrible. I think in general, when software is bad it's because the company wasn't able to make it good. And I think the distinction between those categories is important.
My point was that SalesForce has fairly poor user experience and performance, but does offer the features. It has the additional advantage (for SalesForce) or quick lock-in once the customer commits to it. SalesForce has improved the user experience over time because they have the customer base and revenue to allow that.
Optimization of speed is sometimes it, sometimes it isn't.
I have worked accelerating algorithms in VHDL with a PCI-e interface, embedded linux without a MMU because a MMU uses too many logical gates, digital signal processing systems (FFT, goertzel, sigma delta filters) that had to process a lot of data under uS and etc.
Now a days I work more in the devops space, full stack dev and whatnot. I have worked with a lot of technologies, different constraints, different teams, different companies (12 in total) in different industries.
Trying to paint all business and developers as bad or as cheap because business requirements do not align with your view isn't really fair.
Notably, I’m also not logged in, which might be another thing they’re trying to get me to do and another difference between those who hit this more often than not, and those who rarely or never see it. It’s been like this for years.
If I remember right the app would also crash but it could take bigger loads. Not sure, I uninstalled it.
Yes, that would be unfair.
The first chapter is all about that and how software engineer isn't programming. You seem to think as programming and I believe you're missing the bigger picture.