HN Reader

These days, that is true in Corporate IT. You have the choice of investing real dollars to get things faster, more invested faster it gets. But the speed difference is probably not worth the amount spent. Companies find it easier to throw hardware at the issue then speeding up the program(s). Over 35+ years ago, things were far different, back then we did spend plenty of time and $ in making software run faster.

These days, you have the real possibility the program(s) have a limited life span before the next upgrade. With today's hardware, you can bet you will get more performance per $ spent than by changing the software.

IIRC, I think RMS said something like "do not worry about performance, hardware will catch up". In the case of Emacs, it definitely did.

Is UI performance better in apps where user per-minute labor is expensive? How about apps in a time-limited multitasking workflow?

Bloomberg terminal and some point-of-sale systems were well regarded on interactive performance. What tooling was used to optimize their performance?

If we can use LLMs to rewind/recall activity, can we use continuous profiling (e.g. eBPF) to identify interactive hotspots in complex user workflows?

The computing industry often sacrifices performance for convenience, complexity, or tight deadlines. I focused on making things faster by stripping out unnecessary layers, optimizing core processes, and prioritizing efficiency over feature creep. It’s amazing how much speed you can regain by simplifying instead of stacking. Performance isn’t a luxury—it’s foundational. The key is to treat it as a feature, not an afterthought.