Ok. Now I&#x27;ve heard it from one person. But I think &quot;there&#x27;s almost never the need to have two people continuously coding together&quot; is a pretty strong conclusion from one person&#x27;s experience. Do you mean that you haven&#x27;t noticed the value in it?<p>One possibility is that your team was maybe not so good at it. Sometimes that happens:<p><a href="http:&#x2F;&#x2F;agilefocus.com&#x2F;2009&#x2F;01&#x2F;06&#x2F;21-ways-to-hate-pair-programming&#x2F;" rel="nofollow">http:&#x2F;&#x2F;agilefocus.com&#x2F;2009&#x2F;01&#x2F;06&#x2F;21-ways-to-hate-pair-progra...</a><p>Another is that you were working in a domain where the benefits of pairing don&#x27;t matter so much. For me, they include improved code quality, less siloing, making it easier to bring people on to the team, faster iteration, and a greatly increased ability to actually take vacations due to improved truck factor.<p>On long-lived code bases with high business value and fast iteration, quality and collaborative ease become very important to me. Basically, I put pairing in the same category as code reviews, but I think it&#x27;s much more efficient. And others do as well:<p><a href="http:&#x2F;&#x2F;slesinsky.org&#x2F;brian&#x2F;code&#x2F;pair_versus_review.html" rel="nofollow">http:&#x2F;&#x2F;slesinsky.org&#x2F;brian&#x2F;code&#x2F;pair_versus_review.html</a>