Comment

Comment by jt2190

> But why is slow bad? Fast software is not always good software, but slow software is rarely able to rise to greatness. Fast software gives the user a chance to “meld” with its toolset. That is, not break flow. When the nerds upon Nerd Hill fight to the death over Vi and Emacs, it’s partly because they have such a strong affinity for the flow of the application and its meldiness. They have invested. The Tool Is Good, so they feel. Not breaking flow is an axiom of great tools.

To add some hard data to this, the “eight second rule” [1][2] is the maximum amount of time a user, on average, of a system can wait for that system to return control back to the user without the user having some other thought pop into their brain, interrupting their flow.

[1] Response Times: 3 Important Limits (2010) https://www.nngroup.com/articles/response-times-3-important-... says it’s more like ten seconds

[2] Website Response Times (2010) https://www.nngroup.com/articles/website-response-times/

[3] The Need for Speed, 23 Years Later (2020) https://www.nngroup.com/articles/the-need-for-speed/

Edit: Added reference

Edit 2: Additional reference

Edit 3: One more reference

Edit 4: I think there are still many many opportunities to improve flow in many processes. Top of my list would be keeping compile times in the single-digit seconds.

parent jt2190 4 years ago

Discussion

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton