Speed has a moral dimension: to be fast is to be in tune with the facts of the world as it truly is, as the Atman has provided, without illusion.
Speed has a social dimension: to make the user wait unnecessarily is to express disrespect, even contempt.
Speed has an architectural dimension: to be fast, the operations have to match the parts of the system and their relationships.
Speed has a spiritual dimension: to achieve speed demands that you humble yourself before the structures of the machine as it truly is, not some comfortable abstraction.
I’ve thought a lot about this and one theory I’d like to propose is that there’s people who see software as “on their side” and those who see it as “not on their side”.
I’ve had friends with no programming knowledge love Vimium because it helps them move even faster, whereas a programmer friend doesn’t snap windows even on big monitors. The former delights in finding neat interactions or tools and the latter could care less, it’s “one more thing to think about”. It’s funny, too, because my programmer friend has great critical thinking and logic skills like you’d expect, so this difference is totally unrelated to intelligence. I just think it’s a different relationship with technology.
In relationship to this article, there are people out there who prefer clear, beautiful slow GUIs because it helps them make fewer mistakes. I’m not one of them because I’d prefer to make two mistakes fast than do it slowly, but not everyone is like me.
I actually wonder if it's due to being a software developer.
Over time I've come to realize I'm a software developer who hates software. I love the process of developing software, it's a creative outlet for me, but more often than not software written by others gets in my way. It's a distraction from me being able to solve the problems I actually care about.
It's one of the reasons I still use vim for programming, I've never had it go belly up on me in the middle of editing, or be slow.
Love this and couldn't agree more - sadly it's not something that's commonly measured or marketed, or that the average user seems all that aware of. It doesn't seem to get prioritized by most software companies. But snappy startup, low latency interactions etc. are one of the key things that I look for personally.
>Speed can be a good proxy for general engineering quality
I don't agree. Sometimes things are engineered to be flexible at the cost of speed. Often fast applications are those of limited scope. I like small fast applications but they are not always high quality.
I listened to a presentation from a company that did a/b testing and found out that they sold more when they added an artificial wait to a search (their business was searching for flight tickets). So for some cases people don't believe that software can't do its job properly if it is too fast.
I think I saw the same, I believe it was from Kayak. They said that an artificial loading time increased the user's perception that the search engine made an effort to find the best deal.
Still, worth saying that it's given as an exception that proves the rule that snappier UIs lead to more transactions in ecommerce. The exception was that users couldn't believe that live search in different airlines could be as fast as they made it.
>"I love fast software. That is, software speedy both in function and interface. Software with minimal to no lag between wanting to activate or manipulate something and the thing happening. Lightness."
All of the Unix command-line tools, at least, all of the original ones -- were like this!
But yes, I love fast software (command line or GUI) -- also!
Speed has a social dimension: to make the user wait unnecessarily is to express disrespect, even contempt.
Speed has an architectural dimension: to be fast, the operations have to match the parts of the system and their relationships.
Speed has a spiritual dimension: to achieve speed demands that you humble yourself before the structures of the machine as it truly is, not some comfortable abstraction.