loading...

re: Let's chat about pair programming VIEW POST

FULL DISCUSSION
 

My experience is that pair programming (believe it or not) depends on the pairing.

  • Pair two people with conflicting approaches to a problem, and you get conflict.

  • There is no longer an explicit "code review" step. It's expected to be constant, but this is not always the case. Lack of an explicit step means that the dynamic of the pair determines if they will sit down an review the code afterwards.

  • It's tiring. There is a reason pairing guides encourage frequent switching, it's thats to force breaks. You need way more breaks pairing than you do solo.

So yes, you get two people together who're relatively comfortable with each other and know good design and practices they will produce higher than quality code with a great focus and lower than normal bugs, and the bus factor thing is great.

The question really is, is your team comfortable enough to work like this, or big enough to rotate before friction can get really bad.

Pairing has big benefits, but it can be hard on your teams mental health.

Code of Conduct Report abuse