Lately, I've gotten a lot of flack suggesting that hand optimizing for speed is often a waste of time. Let's drill into that. Your job as a developer is to make your users' lives easier. You discover how to do that through conversations with them (without some intermediary—you don't want to be playing "telephone.") They'll tell you the problems that they're having, and you work together on solutions. They don't "demand" anything, but if you don't keep them happy, you won't have a viable business.

Technical stuff inside the solution is not a user's concern at all. The same applies to "stakeholders," who have no business dictating technical decisions. However, the devs can't just do what they feel like, and often, things that devs deem necessary and desperately want to do (because it's "better," whatever that means) have zero impact on user/customer satisfaction.

The speed issue is a case in point. Sure, if greater speed in certain parts of the program makes the users happier, work on that. If lack of speed has a direct impact on the business (measurable revenue decrease greater than the cost of doing the work), then work on that. Working on speed anywhere else tends to be waste.

It's a common anti-pattern for developers to get caught up in the tech without considering the users or the business. In fact, many developers deliberately distance themselves from both the customers and the business, saying, "It's not my job." Working on unnecessary technical "improvement" does active damage to the business's bottom line, however. Money is spent without a concomitant increase in revenue, and time is added to getting things out the door. Don't do that.

Source: x.com/allenholub/status/1853492121241620887