Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have recently been reading about flow and, since I have experienced this state a few times, I wondered how often an average programmer is able to work in this very focused and balanced way.

Do you know if there are any empirical studies on how often average programmers reach flow in their daily activity, and on how this can influence productivity? I am not asking for a mere list of references to the literature (although these would be interesting) but also for a short description of such studies, if any exist.

share|improve this question

put on hold as primarily opinion-based by Ixrec, GlenH7, Snowman, durron597, MichaelT May 25 at 0:49

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

Regarding the close vote (not a real question): I am asking "if there are any empirical studies on flow and how common it is among programmers, and on its impact on productivity." Possible answers: yes, and these studies are X, Y, Z. Or: not that I know of. If there is any way I can improve this question I will be glad to modify it. –  Giorgio Mar 31 '13 at 20:56
Unless someone has access to every journal, thesis, dissertation or think tank study, how can they answer whether or not any research exists? And if it does, you're asking for a list. –  JeffO Apr 1 '13 at 21:33
@JeffO: Anyone who has worked in the field would probably be able to post one or two key references to the literature, from which other references can be found. I am not asking for a list, but for a good starting point. –  Giorgio Apr 2 '13 at 8:26
@Giorgio, Flow often comes up on the cogsci stackexchange (cogsci.stackexchange.com). It's worth noting, however, that flow has a rather loose definition and is difficult to study as such. –  blz Dec 21 '14 at 18:10
@blz: Thanks for the hint. –  Giorgio Dec 21 '14 at 22:08

1 Answer 1

up vote 13 down vote accepted

Reaching "flow" (or "in the zone" as some people say) is something that depends on so many variables being just perfect. Some that come to mind:

  • motivation to complete(ie, interesting)
  • not being interrupted
  • physical/emotional state(harder to enter it if you are upset about something or are overly exhausted/sleepy)
  • confidence in code (you don't have to sit back and study for 15 minutes before a change)
  • "Knowing" you have a block of free time
  • Random quantum factors
  • probably a lot of other factors

When all of these variables are just right, you might enter "flow" or you might not. The biggest controllable factor you have though is to not be interrupted. If you are in flow, an interruption can completely collapse it and might end your productivity for the day. This is why you see so much content about "do not disturb the programmers!" because an interruption can cause this collapsing of flow.

Also, I mention having a block of free time because it's really hard to get hyper-motivated about something when you have a meeting coming up in an hour. This is why so many programmers advocate for as few meetings and other daily interruptions as possible, or at the very least have them at the beginning of the day. I can never get into the zone when I know I will be interrupted in an hour or two. This is also why I usually don't enter flow until after lunch. On the one occasion I did enter it before lunch I ended up noticing I was a bit hungry at 4pm and had basically lost all track of time from 11pm to 4pm. (Another good tip: keep some snacks at your desk in case this does happen)

Now, even when all these factors are right, you still may not enter flow. I've had one of those "perfect" times when I've sat down to program and just couldn't get into it. Hence, the "random quantum factors". You can't do anything to "enter" flow, all you can do is make it more likely to happen and for it to last longer when it does.

share|improve this answer
Very interesting answer (+1). I found these points especially interesting: motivation, no interruption, confidence in code. Do you know if there are any studies backing these observations? –  Giorgio Mar 31 '13 at 17:49
"confidence in code (you don't have to sit back and study for 15 minutes before a change)": This could suggest that shared code ownership can be an inhibiting factor wrt to flow. –  Giorgio Mar 31 '13 at 17:50
@Giorgio Using a DVCS can mitigate the problems with flow; you only need to deal with others' changes when merging. It also helps if you have a team where everyone respects everyone else's technical decisions most of the time. –  Donal Fellows Mar 31 '13 at 20:19
@Giorgio not necessarily. If you have good test coverage in place, you can make your changes assured that if you did something wrong a test would catch it. That being said, I don't have enough experience to know if writing tests first helps or inhibits flow. I also am no scientist, just giving facts about my own personal experience. I've not heard of any studies of flow/"in the zone" stuff –  Earlz Mar 31 '13 at 20:46
@Earlz: My point was that I can have to study the code for some time if it was modified by someone else since the last time I have looked at it. Having other people modifying the code could be a source of confusion / distraction. But I am not sure about this. –  Giorgio Mar 31 '13 at 21:00

Not the answer you're looking for? Browse other questions tagged or ask your own question.