Flow vs. Collaboration
I’ve been talking about some agile techniques with one of my co-workers, and one of his concerns about pair programming or not being in separate offices is that he won’t be able to get into a state of flow in that kind of environment.
My limited experience with working on projects in group settings leads me to believe that the benefit you get from informal collaboration is far more important, but I’d like some more data.
What do you think? Is the lack of time for flow a real issue, and if it is, how do you deal with it? Or do you find that the collaboration is more important.
I very much prefer working solo. But having said that, some of the most productive times I can think of have involved hammering out an issue with a colleague. Pairs also get into a flow, and when it happens it is superior to any flow I get into when working alone.
The problem is that the flow simply doesn’t exist unless the pairing is a good one. It increases the need for whoever is choosing the pairings to ensure good team dynamics exist. Any conflicts or inability to work in unison don’t just continue to exist when paired, but are instead amplified and can critically impair the progress of your project.
I think people prefer to work alone, so they can get flow, because having flow is really fun! It feels good when you’re kicking ass and getting a lot done when you’re in the zone. Having flow with 2 people is probably way better than with 1, as Greg points out, but I bet its a lot harder to come by 🙂
Programmers are like Carpenters, your have better quality control on your own – but at best you can only build one house and its furniture.
Working collaboratively allows individuals to create programs that are “bigger” than oneself.
I used to believe that effective collaboration required an open space. When I first visited Redmond back in 2000, I took one look at all those little offices and wondered how on earth anyone could collaborate in such an environment. Then, 2 years later, I was working in one of those offices, with the SharePoint team. Everyone I needed to work closely with was along the same hall. If you wanted to talk, you left your door open, and if you didn’t, you shut it… and it was one of the best collaborative environments I have experienced as well as incredibly productive. In fact, thanks to the individual office design, more people were within range than in an open plan office (where you have to provide each person with a lot more space just for noise management, and people have to go find a meeting room if they need to be on a conference call). Completely changed my perspective – and I had been a collaboration specialist for 10 years!
I believe it depends on the situation. One way that has worked well for me in the past was to have an individual work space for everyone, but during crunch time, take over a conference room for a few weeks. When you want to collaborate, go to the room. If you need to focus and get into a flow state, go to your desk.
Eric,
You are cordially invited to building 5 at any point that it is convenient for you. Inside patterns & practices, all our development work is done in a shared space, and much of it is done through pair programming. Peter Provost, Brad Wilson, and I have done several web casts and podcasts on how essential our war room culture has been to our projects’ success inside Microsoft.
We’d *love* to have you come over and learn about what we do. I’ll drop you a note through internal mail, and invite you again through there.
— bab
My experiences with flow in both single and pair configurations:
– Flow is not a constant state of mind during a workday, wether you work in pairs or single, it can be there and sometimes it’s absent. I think flow is overrated.
– To work around the absence of flow and still be productive is underrated.
– 1 + 1 = 3, even if pairs don’t match at first. I’ve seen many impossible pairs turn out to be good and highly productive friendships, with and without flow.
– Good pairs know when to shutup and see/listen/concentrate or whatever. Just like marriage.
This guy that I work with wrote this in his blog:
"In the years before Microsoft, I wrote a lot of code, and I miss that feeling of immersion when you realize that 4 hours have passed without you really noticing. It’s a state of being as much as a state of thinking."
Even though it’s a little heavy on the Zen, I can’t agree with him enough.
Personally, I try my best to work out of the office as much as possible whenever I have a lot of code to write. This isn’t so I can watch Oprah in parallel, but because each interruption puts my solutions at risk. If I’m an hour deep and in a hung process with eighteen threads that share six locks, a pin drop could render that 60 minutes a waste. This isn’t to say that I do not use and see my coworkers as valuable resources. I talk to other devs before I do anything big, or keep those working in the same code apprised to situations and design changes. I guess it comes down to a question of granularity. Should you consult on each class? method? line? I think I could deal with the class level.
On the other hand, your coworker is probably just hiding the fact that he can’t read, and has outsourced the transcription of his code to India. Could you imagine if another person were in the room while you were dictating for-loops… Have a heart, it’s Christmas.
One word: Headphones
Couple this with a small team (say 4-6 people tops) sitting back to back.
If you have them on someone should have a good reason to disturb you. If not you are available for the collaboration.
Most productive environment I’ve ever been in – but needs decent people (or at least ones that learn fast)
Matt
There is no conflict between flow and collaboration. I have never been more focused during a programming session than when pairing and constantly changing places. After 30 mins my head can be completely drained, but that is no problem because then my partner takes over and the flow continues.
(I’d love to come to building 5. Too bad it’s half way around the world. 😀 )
I’ve tried the pair programming route a number of times – with various degrees of success.
The first we did it, I just assigned a few times to do it, and we tried it for a few weeks. Everyone agreed they felt less productive and enjoyed the experience less. However – those teams over those weeks actually achieved the highest velocity of the entire project – so it worked – it just wasn’t pleasant.
I tried it again with various other teams in different ways, and had a mixture of success, until we finally came across something that everyone really liked AND was productive – and it came down to MSN messenger’s remote assistance.
There’s lots of ways to use another person’s machine, but Remote assistance is one of the few that allow both people to use it at the same time, with no transfer of control… We found that if we made a remote assistance connection, each person stayed at their own machine, we wore headphones, and had little video screens of each other on the screen, whether you were in a different city or literally 2 feet away – everyone found it a better environment.
You sort of feel "in control". You can type, you can move the mouse if somethin’s going too slowly… and having the headphones on locks out the rest of the world – you just talk and a voice responds :)….
Try it – it’s a very effective (and productive) way to pair program.
I’ve been talking about some agile techniques with one of my co-workers, and one of his concerns about pair programming or not being in separate offices is that he won’t be able to get into a state of flow in that kind of environment. My limited experienc
PingBack from http://aron.getyourfreehealthvideo.info/headflowvsvelocity.html