How to you achieve and maintain flow while pair programming

flowpair-programming

Flow is a concept introduced by Mihaly Csikszentmihalyi; in short, it means to get into the "zone". You feel immersed in your task, focused; the task can be difficult but challenging at the same time. When people achieve flow their productivity shoots up. Programming requires a great deal of mental focus because we often need to juggle several things in our minds at once. Many like to work in a quiet environment where they can direct their full attention to the task. If they are interrupted, it may take several minutes or even hours to get back into flow.

I understand there's a practice in agile development and extreme programming called pair programming. It means you put the whole software development team in one room so that communication is seamless. You do write code with your pair because this way you get instant code reviews and fewer bugs get through.

I've always had problems achieving flow while doing pair programming because of constant interruptions. I'm thinking deep about an issue then all of sudden someone asks me a question from another pair. My train of thought is lost.

How can you achieve and maintain flow while pair programming?

Best Answer

Edit: Disclaimer - This is how I define "the zone": A state of extreme focus, in which one is able to understand how many intricate details connect together, regardless of whether these do so elegantly (or simply) or not.

I try to avoid this state because, while I may produce correct code in the zone, I and other developers will have a hard time understanding it later on. To put it short: reading code that was written in the zone may often require the reader being in the zone. That constraint is my problem.

There's a lovely chapter on The Clean Coder where Uncle Bob persuasively explains why "getting into the zone" is a delusively bad idea.

Here's a possibly better alternative than "getting in the zone": think straight and consider calmly and professionally what you're doing. Communicate. Share thoughts with your partner(s). Identify the real problems. Discuss possible solutions. You might not feel supernaturely focused, but you're likely to make good decisions, and approachable designs.

If you and your pair-partner can discuss the problem without both of you being extremely focused, then chances are you've boiled the problem down to its simpler nature. That suggests you'll be able to understand it again whenever you need to.

On the flip side... If you just need some time alone to get your head straight (we all do sometimes), just take it. Get your thoughts together. Work the problem out in your head first.

But the thing is that if you do - don't use that time to write production code. Instead, play around with sample code and prototypes. Try to understand the problem, without thinking about solutions just yet. Once you get everything straight and written down, discuss it with your team and pair partner, or even the rubber duck on your desk. If you still can't articulate it, or they can't understand it, then refine your ideas. Once you've nailed all of that down - integrate all that thought and sample code into a real, working solution.

Related Topic