flow?

Recently I’ve been hearing a lot about the concept of ‘flow’ when working on software.  That is, the idea of there being some special mental state that a developer needs to be in to be at his/her most effective.  I’ve seen it referenced in software team management books, heard it mentioned around the office, read about it on the interwebs.  It’s supposed to be this delicate balance of lots of details in a developer’s head at once, where disrupting him in the middle of things sets him back to square one, wasting the dozens of minutes that it will take for him to resume ‘flow.’

I can’t really speak about anyone who’s not me, but I don’t feel like this is the way I work on things.  In general I take a lot longer than 20 minutes to get an idea of how things fit together (for example, I’ve been working on GeoServer for about 10 months now and I’m still picking things up) and a lot longer than 1 second to lose track of it all.  In fact, one way that I approach tough problems (ie, those that my initial ‘bang my head against it for a couple of hours’ approach fails to resolve) is to just go work on something else and come back a (subway ride, weekend, couple of hours later) and find that I’ve come up with a decent solution subconsciously in the mean time.

I think this concept of ‘flow’ feels like a good way to promote antisocialism in development teams, deemphasizing communication between developers to promote a team of cowboys working on code that requires a lot of headspace to work on.  It feels to me like it would be a lot better to keep communication frequent (keep the bus factor high, that kind of thing) and if it makes simple code a necessity in order to get stuff done, all the better.

So.  What can be done to avoid needing flow?  I find that it’s easier to slip in and out of development when I have a specific behavior I’m looking for, basically a test-driven development model.  Another thing that makes it easier to keep my place is a graphical debugger, which lowers the amount of headspace I have to devote to modelling the software behavior.  Finally, decent documentation (even if it has to be in the form of bugging another developer in an IRC channel) reduces that same headspace requirement by helping me to figure out expected or intended behavior more directly.

Maybe I’d think differently if I worked in an interpreted language; I have little built-in interruptions all day long when I restart GeoServer to try out changes I’ve made.  But I am definitely wary of anything that discourages communication between developers.