Working in pairs bring benefits, such as constant code review, knowledge sharing, improving team spirit, help applying good practices under pressure, and design discussions.

Sometimes, situation occur when the reasons for pairing can be questioned. For example working with code that the team understands and is very unlikely to introduce bugs, like style changes to a web page. The code produced during these sessions might not need code review, and there’s no knowledge to share in the team.

Another reason pair programming get criticism is because it collides with something developers are known to love, namely spending hours and hours on code without interruption, being in the zone or having flow. But even though I’ve only been pair programming a few months, I have definitely witnessed the existance of pair flow. When working alone, I’m usually easily interrupted and need music or complete silence to stay there. If the task is boring, or if I get completely stuck, my mind can easily drift and I am likely to take up something else. In my experience, getting into a pair flow is much easier than the solo equivalent, and it is possible to keep up the pace even though the environment is a noisy. The pair’s discussion will simply mute the environment. When you get stuck, you can talk your way through it and boost each other’s morale when you’re feeling like throwing it all away.

Sequential pairing is a kind of hybrid between solo coding and pairing, for those times when pairing feels unnecessary but you still want a bit of a sanity check before you check the code in. One developer completes a short and easy task, and simply hands the result to a colleague who can review the work and commit it. That way, you get a new set of eyes on your work, and you also share whatever you did for possible improvements, or a potential hand over.