Comment by jt2190 | Hacker News Reader

Comment by jt2190 | Hacker News Reader

> 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.

Sadly, the future of software is to become bloated and slow, for business reasons. Any software that is not bloated has fewer features, and can be relatively easily duplicated by a competitor. From a business standpoint, this is bad and a danger for the company survival, as it can now be replaced by a competitor that can crank more features into the product. By adding more features, companies pretty much guarantee that the software will also be slow, at least for a significant number of user cases.

as long as free software allows users to choose fast software instead of business software this shouldn't be a problem, but the web browser disaster is an instructive tale of how this can go terribly wrong

Open source suffers from the same problem I mentioned above. The difference is that the goal is not money but market share.

but at least in theory we can keep using less-featureful versions of open-source software if we like, even fork them

i mean people are still using tvtwm, rxvt, and lynx

That reference is from 1993... I think people's attention span has shortened since then...

> I think people's attention span has shortened since then...

Unlikely. Rather, what I think has happened is that as the internet keeps filling up with more and more trash, we have been forced into being harsher with our willingness to pay attention to any one specific thing. In other words, it’s not the attention span that has changed. It’s the signal to noise ratio that keeps getting worse and worse. And that’s why you need to demonstrate value to your audience quickly or otherwise they will move on to the next thing. But don’t blame the audience for that. Blame the producers of the content.

What you’re calling “attention span” is probably more accurately called “user expectations”, or “user patience” which, obviously, can easily change.

On the other hand, there seems to be a measurably consistent maximum amount of time that one can tolerate a pause without also breaking out of flow. This might be cultural, but it seems to be consistent enough that it could be physiological.

Agreed, 140 char replies instead of paragraphs, and rapidly scrolling TikTok videos. We need that dopamine.

That’s a myth: https://www.bbc.com/news/health-38896790.amp

A friend of mine has a very interesting view with regards to flow: It is a bad thing. You don't want to be in a state of flow, because you are not thinking hard enough about what you are doing then, but just following the flow.

I don't think I'd go as far as to claim flow is bad, but there's something to that.

I'm a long term emacs user and between changing keyboards a few times and an unfortunate spell of a few years using an IntelliJ-based IDE with Emacs Keybindings that are far better than most but inevitably off (most infuriatingly, to conclude an incremental search you use Ctrl-g, which in actual emacs jumps you back to where you started the search) my reflexes are all over the place. I'm therefore having to force myself to slow down and be consciously aware of everything I do.

I'm finding it a really useful exercise for more than just the retraining aspect. It does seem to increase my overall engagement with the task I'm carrying out, beyond just the operation of the tool.

Being in the flow is not being on automatic.

It's the absolute opposite, you are totally conscious about what you are doing, and clear headed about the decisions you make.

It does feel effortless, but not in the sense that you are not doing the thing consciously, rather in the sense that the thing seems so obvious and easy as you perform in perfect fluidity.

That is a very _interesting_ take. I think it's ~wrong but, like most interesting takes, there's some truth to it. I think the "truth" here is that, well yeah you're not thinking about some things, that's literally what I consider flow, it's not thinking about **how** you're going to do X but it's higher level than that and focusing on "do x".

I think it's the difference between thinking/taking the action "walk to the door and open" (X in the flow state) and "ok get up, left leg forward, right leg forward, left leg forward, right leg forward, move arm to door, grab, twist, pull". Flow is just not thinking about the things that are not important (a lot of code is just gluing and can be done in a flow state - still allowing you to stop and think about the real important places). What your friend is calling out is that yeah I guess that sometimes you can "automate"/flow things that actually are important but to be honest I don't think that happens very often in this context (software, real use(r)-cases) because their use-case are usually so narrow and specific (we should design software to allow them to "flow" the unimportant stuff - click next for the additional questions - did you notice the button responds on mouse click up? I hope not, I hope we made that piece "flowable")

There is something to be said about flow in mechanical activities, because on those, yes, you are mostly not thinking, just following the "rhythm". Safety is normally one of the first things to get out of your head during that.

But programing is nothing like mechanical activities.

But the act of typing on the code and running/debugging it should be. Any toolset where you have to wait excessive amounts of time just to be able edit/ compile/launch/debug/review results is not really going to make you think more carefully about your code (an exception could be made for super long compile times, which do force you to be more careful with what you input, but I'm not really convinced it can help you write better code).

Programming for me is both:

- reading and understanding existing code

- a often very goal oriented activity (but sometimes exploratory) where I (try to in the latter case) transform a part of the system according to my visions of a better system

- the mechanics of moving the caret around (arrow keys, file selection), selecting text (shift and ctrl modifiers in addition to arrow keys), using shortcuts to invoke pre defined transformations (automated refactoring) etc.

It is the thinking I get paid the good money for.

But if I was constantly struggling with my tools then it will take more time and I would get exhausted faster.

> the mechanics of moving the caret around

You can't hurt yourself moving the caret around.

I thankfully don't suffer from it but ask anyone with RSI about that.

My broader point however is that if even a small but non trivial part of my brain capacity must be used to deal with the mechanics.

In a way it is like when I learned to use a climbing harness for work and learned to trust it, the effect on my output when I worked in the field was amazing because everything I did was no longer interrupted by constant considerations and adjustments to stay safe.

being in a state of flow as defined by csikszentmihalyi has nothing to do with 'just following the flow'

on the contrary, it is when you are in a state of flow that you are thinking hardest about what you are doing

it sounds like your friend got confused by a random coincidence of word meanings

The way it has been described to me is that if you always take the same route to work then your cognitive performance goes down. Staying curious and exploring the different routes is hard with relatively few waypoints but then you can zoom into more granular decisions (or out ... to the causes).

I can see where your friend's coming from - but I'd disagree up to a point. It's about which aspects you want to be in a state of flow.

If you've used a computer for any length of time, then when you type you're not thinking about the act of pressing each key - you're probably thinking several words ahead of your fingers. If you type half a dozen characters and nothing happens on-screen, then they all appear at once three or four seconds later that would be an intolerable break of flow. (And happens more frequently today than it did when computers were literally 0.1% of their current speed.)

If you're driving, you don't want to be thinking about the act of reaching for the gearstick or indicator stalk, but you do want to be thinking about what's happening on the road - so there you can indeed take "flow" too far.

On the other hand, if you're performing music, your fingers need to be in a state of flow in order to free you to concentrate on the emotion of the music - yet that, too, would ideally be in a state of flow...

That is not what I experience. The thing I refer to when I refer to "flow" or being "plugged in" or "in the zone" is that all of the relevant paradigms and information are in my working memory.

When I'm in a flow state, I see and understand not only the function in front of me, but the functions it calls, the functions that call it, and the data structures involved. I can see the tree in minute detail at the same time I can see exactly how it fits into the ecosystem of the forest.

It isn't that I'm not thinking hard. It's that thinking hard is possible, rather than interrupted by a constant need to regain context.

Interesting take, you're supposed to think about what needs to be done before 'going into the flow' to do it.

But yes, sometimes this waste time because you discover afterwards that what you did wasn't what should have been done, if you were less focused on doing it you may have changed your mind before.

A long time ago, I used vi instead of Emacs because it was much faster.

Recently I tried to replace VSCode with something else because VSCode isn't responsive enough.. But vim is annoying to customize as a C++ IDE, so I tried SpaceVim and I discovered that it starts even slower than VSCode :-( so I'm still using VSCode..

Reply on news.ycombinator.com