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?

  • 4
    I don't agree that other pairs can just interupt at any time.
    – JeffO
    Commented Nov 18, 2011 at 4:07
  • 3
    An alternative to Flow is to identify and maintain position at the Ballmer Peak. This may take a good amount of experimentation, time, and Scotch to achieve. Commented Nov 18, 2011 at 21:33
  • I'm distracted reading this question when I should be writing code. If I was pair-programming with someone, I wouldn't have opened this question to read it, and would presumably be getting more done.
    – TehShrike
    Commented Apr 12, 2018 at 15:48

5 Answers 5


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.

  • 2
    I'd upvote a million times if I could, professionals learn to work whether they are "in the zone" or not. Professionals can work with peopleinterupting them to ask questions, with noise around them, and together with other people actually having conversations about how to do whatever task they are working on together. I'm not interested in working with prima donnas who have to have special working conditons to concentrate.
    – HLGEM
    Commented Nov 18, 2011 at 21:24
  • 8
    @HLGEM - I don't think having access to a quite place to work when needed is too much to ask for.
    – JeffO
    Commented Nov 19, 2011 at 11:36
  • 2
    @HLGEM: Of course a professional is supposed to have average productivity under average working conditions. But on the other hand it would be in the employer interest to let the same professional work in a very focussed way, because this can enormously increase productivity and quality.
    – Giorgio
    Commented Mar 31, 2013 at 17:18
  • 2
    "It seems to me that people treat "the zone" as if it were some magic quick fix for solving problems well, like a thinking hat.": No, more trivially, the zone is a state of concentration in which you are more productive because you are focussed on your task with no distractions. The zone does not make you almighty, it only makes you more productive.
    – Giorgio
    Commented Mar 31, 2013 at 17:23
  • 3
    @Yam Marcovic: This is not the kind of productivity I had in mind (producing more code of lower quality): if one uses isolation as an excuse to do what they want they are not being more productive. For me flow does not mean to mess around and then writing down a lot of code, but rather to systematically work on a specific task without being interrupted by other, unrelated tasks.
    – Giorgio
    Commented Apr 1, 2013 at 13:37

Pair programming sometimes requires periods of isolation from your partner.


You are working together on a particular class, and you realize that you need to write a method that requires deep thought on some complex logic, but otherwise returns a mundane result. You work together on creating unit tests for that method, and defer the writing of that method to a period of time when you're working in isolation. When the method is completed, you get back together as a pair and evaluate the results.

  • Why should the implementation not be made in pair programming? Commented Jun 17, 2016 at 12:06

I've found there is a small class of problems for which pair programming works. For example, if you are working on a cross platform product and the Winders guy has implemented a feature that requires OS specific code, he can help the Mac guy implement the same feature on the Mac code while the Mac guy drives.

However in my experience pair programming unusually results in a net loss of productivity. It so often feels like we're paying two developers to do the job of one.

Yes, it reduces the horrifying possibility that a dev might take a stackexchange break during the workday.

IMHO it would be cheaper for those companies who want to police their devs to just pair every dev with a private security guard to stand behind the developer and hit the dev with a truncheon if he ever slows down or tries to peak at a non-essential web page.

  • 1
    The point of pair programming is not stopping each other from slacking off; that wouldn't even be effective. The point is having code review in real time.
    – Lev
    Commented Apr 2, 2013 at 10:03
  • 3
    @Lev: Having a code review before committing is much more efficient: the review takes from a few minutes to half and hour, instead of an entire workday.
    – Giorgio
    Commented Dec 18, 2014 at 12:06
  • @Giorgio Not quite. For example, it can so happen that you make a bug, then waste time catching it, and only then get your code reviewed and commit. If you had pair programmed, your partner would have noticed the bug and saved the debugging time.
    – Lev
    Commented Dec 21, 2014 at 11:35
  • 1
    @Lev: "If you had pair programmed, your partner would have noticed the bug and saved the debugging time.": There is no guarantee that a bug is noticed either with pair programming or with code reviews. E.g., after six hours of pair programming one might be so tired that one easily overlooks bugs.
    – Giorgio
    Commented Dec 21, 2014 at 13:38
  • Obviously there is no guarantee, but it can help.
    – Lev
    Commented Dec 24, 2014 at 9:39

As a developer attempting to get into the zone, you'll attempt to isolate yourself as best as you can to get comfortable and clear your mind. Why should pair programming be any different?

You and your partner should find a zone-inducing environment that works for you both. This will possibly require compromise on some things, but my main point is that the pair environment should be similar to the solo. Turn off the external world. The pair is programming together; other pairs (other co-workers in general) should not be interrupting (excepting critical, drop-what-you-are-doing problems).


Flow is a great state to be in when you know the exact steps to solve a problem. i.e. few unknown unknowns. You sit in a quiet corner and hammer away the solution. However, most problems/stories/features are not very clear when you start programming them. There will always be a "gap" between the end state expected and how your brain has "planned" it. You learn a lot of things when you actually "do it". Your brain juggles

  • Code Design

  • Typing

  • Learning new things about the domain and code

When I program alone, I struggle to balance these things. I tend to get into "rabbit holes" where my sunk cost fallacy prevents me from taking a step back and looking at the big picture and changing my design. It is also hard for me to talk to an imaginary rubber duck or a real one for that matter. I am after all in "flow".

When I am productively pair programming though, I get alternating periods of typing followed by periods of thinking and reflection. This is where a lot of hidden things reveal themselves and a different design may emerge. If I am going into a rabbit hole, my pairing partner can pull me out of it. Talking/explaining something to a real human being has this wonderful effect of making your thoughts clearer somehow. Sometimes, I do miss being in the "flow", but I think I contribute much more to my team when I pair program than when I program solo. After all programming != typing. Programming happens in the brain and better programming happens when two brains collaborate and criticise each other.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.