Pair Programming And Flow

Can a pair working together achieve mutual flow? Does PairProgramming lead to Flow, or is it something else? Seems like there's a school of thought that people should have their own offices with doors (Peopleware) and then there's the PairProgramming work layout idea. P.S. sorry about munging this page earlier; I.S. where I work has things setup up so that my browser is constantly colliding with the company firewall. So I guess I'll only try to do edits from home. -- MarkYoung?

My experience is that pairing creates and maintains flow better than individual work. Think of it as like dancing or ping-pong: without a partner it's much harder to get and stay deeply involved with than it is with a partner. It's also easier for pairs to handle distractions; one partner breaks away and deals while the other maintains the flow. Then the first just merges back in very rapidly. We have a codephrase for that here: "Okay, now where were we when the rope broke?" And of course pairs don't get interrupted as often because two people working together look busier than one person. -- PeterMerel

Does PairProgramming prevent Flow?

I had the pleasure of seeing TomDeMarco speak in XpImmersionThree. Someone asked him about the contradiction between his outlook on facilities and XP's. Afterall, we heard him say that "XP is the only game in town."

In PeopleWare, TomDeMarco discusses the importance of private offices and few interruptions to allow for the Flow. XP prefers an open workspace to facilitate face to face communication and PairProgramming.

TomDeMarco said that he believes that there is a completely separate phenomenon from Flow that takes place in groups. He said that psychologist Mihaly Csikszentmihalyi's discussion of Flow discussed solitary activities like playing the piano. A well tuned hockey team or an orchestra, on the other hand, is experiencing something completely different.

This is referred to by some musicians as the band being `tight'. As with other terms, it might be appropriate to just qualify the context: solo versus group flow. Or just adopt the jargon from our musical friends.

So I think he did a 180 in favor of the XP way.

I've experienced both states at work. The group version tends to keep me more on track with a goal. I find the solitary version more suitable when I'm having fun at home because, in Flow, I enjoy the act of creating more than the results I produce.

-- ArmandoSinger?

I concur that in a harmonious community, the synergy one gets is equivalent to the MentalStateCalledFlow, whether named as such or not.

I find pair programming to get in the way of flow. I suppose this is because I usually end up in the Mentor position and either have to stop every couple of minutes while driving to explain what the heck I'm doing, or have to worry about the little details when not driving so I can't focus on the big picture. -- BrianRobinson (focus on the big picture is a contradiction in itself!)

The "mentor" should not be doing the driving, otherwise the knowledge gap is only going to widen. Your partners may be too insecure to admit this, but there is no way they can catch up with you if you're driving and they're just along for the ride. Even if you split the driving time evenly between yourself (the mentor) and your partner (the mentee), you should realize that the learning ability of the mentee is only going to be a small fraction of your own ability, and the knowledge gap will only widen exponentially. There is also something to be said for not focussing too quickly on every little mistake of the driver. When I'm not driving, I am usually jotting down notes because I am thinking ahead and I am usually jotting down the mistakes instead of blurting them out right away. -- StephanBranczyk

Although most of the folk in my group PairPromiscuously, I have an excellent engineer who used to report a similar experience. The trouble he was having was a matter of focus; he was worried about the flow of his own work much more than that of his partners, or of the group as a whole. As time went on his focus changed, and flow in pairing with him became much easier. Flow in pairing is a matter of harmony between developers, I think. But of course YMMV. -- PeterMerel

Pair Programming in counter-intuitive to achieving flow! Flow is total and utter focus on the job in hand, to the point of "automated programming" (your hands are writing the code for you and you will be assured to forget that you even wrote it in the first place!) - Pair programming means mandatory interruptions! -- Ben Duffin

CategoryPairProgramming CategoryConcentration