Flow, Stuckness, and Interruptions









Weinberg, Gerald. The Psychology of Computer Programming.

Brooks, Frederick. The Mythical Man-Month.

DeMarco, Tom, and Tim Lister. Peopleware.


Ruby Sinreich said...

Helpful and well-put. Thanks for this post!

Anonymous said...

Well said (as always)!

I've been trying to communicate this to my bosses, with little success. Since my work is almost entirely interrupt-driven, with the interrupts being quite unpredictable, getting anything done that requires problem-solving is almost impossible.

We are banned from doing any work whatsover related to our jobs outside of the hours during which we are clocked in, yet there is little time to think then. While we may have entire hours during which no customers interrupt us, we have to maintain a state of attention to them that prevents us from entering flow mode. I've had a long memo forming in my head about simple fixes that will make our store computer systems far easier to use, but I never have a chance to actually sit down, organize the thoughts, and write it.

Harrison Bergeron lives. *sigh*

Anonymous said...

Thank you for so eloquently putting this down on [virtual] paper. This post is an excellent description of exactly what goes on in programming with respect to interruptions, and extends far past the business/workplace environments; my personal experience is identical when programming for work or for pleasure, except with one major difference. The level of frustration at interruption during a flow period at work is much less than that during play. While at home, interruptions from family members can be both very demanding and very annoying. Just another look at the matter from what may be a more practical perspective for many of us super-geeks.

Anonymous said...

Nice essay; it really captures to mindset of the lone programmer.

I find that explaining the problem to someone else is the best way to get past stuckness. Often it doesn't even matter whether they can help - just launching into an explanation is often enough to help me think of a solution. (So, if nobody else is available, explain the problem to your cat.)

Of course, unless you're pairing, asking for help is someone else's interruption.

John Cowan said...

Brian, see the description of Teddybot, an IRC bot designed to help with this problem. He mostly just says uh-huh and go on, but occasionally spews one of Brian Eno's Oblique Strategies (hi, Joe).

I note that most of the comments here and elsewhere (kai Technorati) focus on the badness of interruptions in flow, rather than the goodness of interruptions in stuckness. Hmm.

Anonymous said...

So how do you deal with external depenendencies on your project if you don't want any deadlines?

Joshwa said...

see also:

Flow (wikipedia)

MentalStateColledFlow (c2 pattern wiki)

Flow: The Psychology of Optimal Experience by Mihaly Csiksczentmihalyi, the psychologist who came up with the term

Pradeepta said...

Not very different from link fixing a motorcycle is it?

Peter Arrenbrecht said...

Well said indeed. What struck me recently is that slow edit/debug cycles much more severly affect performance than is explained by the cycle-time itself. This is because, in my experience, having to wait for the system for too long can do one of two things: (a) make me think about what I am just doing, or (b) make me slouch off to the Internet or a magazine article or an interchange with someone else (which, incidentally, breaks their flow too). Given that the reddit et al. are always beckoning, choosing (a) is getting rare. So waiting often breaks my flow.

I am thus led to believe that, quite apart from all its other benefits, test-driven development is extremely good for keeping you focused. This is because, in this style, you typically build fairly isolated tests that have quick edit/debug cycles, rather than having to launch an entire application, click your way through it for the nth time, etc.

Anonymous said...

Noting Pradeepta's posting, should not Robert M. Pirsig's "Zen and the Art of Motorcycle Maintenance" be in your biography. I thought he coined the word "stuckness". Correction cheerfully accepted. Would really like to know.

John Cowan said...

Zen and the Art of Motorcycle Maintenance is a wonderful book. Consider it added!

As for who invented the word stuckness, it's an obvious compound made of two productive parts stuck and -ness, so anyone could have invented or reinvented it at any time.