Thanks for your comments!<p>&gt; I don&#x27;t see how &quot;promiscuous pairing&quot; helps with most of them.<p>Maybe you should try it! The &quot;promiscuous&quot; part transfers context and knowledge around more quickly, and gives more opportunities, earlier in the process, to respond to feedback from a wider variety of perspectives. Two people might come to the same conclusion that another, joining a couple of hours later and without following the same mental path, would find crazy. It&#x27;s generally pretty easy to change direction after a couple of hours.<p>&gt; Pairing by definition slows down all work on code(you have 1 person working instead of two).<p>&quot;Work on code&quot; is not all that&#x27;s involved in shipping product. In my experience, pairing produces less&#x2F;simpler&#x2F;better code that more directly addresses intended business value and cuts off unproductive paths more quickly than other methods. I much much much prefer cranking out less of the right code than producing tons of &quot;perfect&quot; code that solves the wrong problem (slightly hyperbolic, but you get the point, and it totally happens all the time). It&#x27;s worth mentioning that what I&#x27;m talking about is pairing done well, by people who have learned how to do it well. It&#x27;s absolutely possible to do a shit job pairing, as with anything else.<p>&gt;* They tend to encourage focus on abstract code polishing without proportionality or relation to the value of the code.
&gt;This is an issue with the priorities of the people doing the code review, and thus applies just as much to pairing.<p>This is true to a certain degree, but good pairing typically involves thousands of little tradeoff decisions and discussions about how to solve problems. A code review can&#x27;t reproduce the richness of all of that communication, so it necessarily emphasizes code in the abstract over deep consideration of the tradeoffs involved in the solution to a problem.<p>&gt; I have no idea how pairing is possibly different from code review in [the case of superficial improvements.]<p>When I&#x27;m sitting down with someone to solve a problem and we explore a path for a few minutes, then I can step back and say, &quot;wait, based on what we&#x27;ve just done, I think we&#x27;re thinking about this whole thing in the wrong way, what about this other thing,&quot; it&#x27;s easy to turn around and explore a totally different approach. When somebody has sunk an entire day into solving a problem, polishing the code to impress their coworkers, and responding to code review comments, it&#x27;s extremely difficult to say, &quot;hey, I think we&#x27;re thinking about this the wrong way, what about this other thing?&quot; I&#x27;ve experienced this problem nearly every time I&#x27;ve participated in code reviews and rarely during pairing. (To that point, pairing is such a better dynamic for this type of exchange. A code review has an oppositional nature, while with pairing, you&#x27;re literally on the same side of the problem, sitting together to find a solution. The dynamic of questioning the path&#x2F;approach starts off in a much more natural&#x2F;friendly&#x2F;collaborative place.)<p>&gt; so the most egregious problem with code reviews is the people that do them might have wrong priorities<p>I think it goes beyond that. As mentioned above, the structure of code reviews (vs. pairing) favors certain types of feedback over others, and makes the feedback that I believe to be most valuable very difficult to give, socially, and too late to be really valuable.<p>&gt;A benefit of pairing that I can see over code reviews is when you get feedback - instant, real-time in pairing vs late in code reviews.<p>Yes! Exactly. And from what I&#x27;ve seen, this makes an enormous amount of difference.<p>I don&#x27;t agree with you about the time differences, especially when considering the full cycle of delivery. It&#x27;s a notoriously difficult thing to measure effectively and&#x2F;or prove, so...it&#x27;s one of those things you have to experience first hand (in an environment where it&#x27;s done well...there are plenty where it&#x27;s not) to really buy into perhaps.<p>It&#x27;s also true that some people just want to work solo. I&#x27;m motivated by producing the best possible product and generating the best possible outcomes, and pairing is the best way I&#x27;ve encountered to do that, so...in general, I&#x27;d prefer not to work with those people when they&#x27;re steadfastly opposed to trying collaborative work. At the same time, I&#x27;ve found that most people who give it a shot with a good pair who has some patience, empathy, and skill, end up loving it. Even folks who generally work alone.