Yea that never made sense to me. I think and solve problems as I code, and having someone yapping while I'm trying to do that is a great way to disrupt my thinking process.
You might be working on much smaller and well constrained problems, pair programming works well when the problem is unconstrained with many complex and interconnected layees
In my limited experience, the 'pairness' part of pair programming , is best done in silence. The discussion / planning happens up front, the keyboard person does the implementation and the second person doesn't 'backseat drive', but thinks about test cases (writes it down), thinks about weaknesses (writes it down) and writes documentation while the code is written.
All of these are reviewed before commit.
The 'interrupting' while coding is the shitty part (I agree with you), not having someone working with you.
Yea that never made sense to me. I think and solve problems as I code, and having someone yapping while I'm trying to do that is a great way to disrupt my thinking process.
You might be working on much smaller and well constrained problems, pair programming works well when the problem is unconstrained with many complex and interconnected layees
Maybe it does for you, but everyone is different. It is annoying (and sad) to see both sides asserting their experiences as universal truths.
I cannot stand pair programming, but I don't begrudge that it might work for some.
In my limited experience, the 'pairness' part of pair programming , is best done in silence. The discussion / planning happens up front, the keyboard person does the implementation and the second person doesn't 'backseat drive', but thinks about test cases (writes it down), thinks about weaknesses (writes it down) and writes documentation while the code is written.
All of these are reviewed before commit.
The 'interrupting' while coding is the shitty part (I agree with you), not having someone working with you.