Positive ways of getting into the flow is something we haven't touched on so far, although we are aware of the need for and strive for a good working environment with relatively good levels of quietness. What we have been actively working on (with a good level of success) is avoiding unnecessary interrupts.
What is the problem with interrupts? Don't you just hate it when you are six levels deep in code and your manager walks in to say to the team: "Hey guys, don't you think we should transmogrify the hubbleity widget?" Instant loss of concentration and exit from the zone, only to struggle to get back to where you were.
One research study (blog post, research paper) examined developer behaviour of 414 developers in 10,000 programming sessions and found that for developers in the sample
- Devs took 10-15 minutes to resume editing code after an interruption.
- Devs were likely to get only one uninterrupted 2-hour period for development in a day.
Both of these are alarming statistics. Avoid interruptions at all costs. As a practical measure we identified what each of our devs was doing when zoned in or not zoned in, and now we just look for these behaviours before asking something. For example:
- May be zoned in: Wearing headphones can be a sign of being zoned in.
- Definitely zoned in: Not looking at ancillary sources for information on the web, and only focusing on and flicking between vi buffers or IDE tabs.
- Not zoned in: Looking at a mobile (cell) phone.
Better still, we have adopted gmail chat and email for question requests, knowing that a developer will ignore these until having left the zone. Similarly, to remove more potential interrupts when I need to disappear from the office, theres a Where's Mark corner on one of our whiteboards, I simply write where I am and when I'm expected back there, and avoid the need to announce that to the dev team when I leave.
Of course pragmatism still rules, we can still interrupt, but we only use that for emergencies.