I think it depends on the nature of the task and on the experience of your pair.
If the task is more mundane, you get someone to think about corner cases and other consequences while you code, or vice versa. This is a great way to onboard beginners, as you constantly show not only your code but your process and tools.
If the task is more exploratory, a second person might still be helpful, specially if it is someone with more experience; they can provide real time feedback on your ideas and it might be valuable.
For me, it is not just about getting the work done, it is about knowledge diffusion and code quality - I can't remember now and didn't search again, but there is some data gathered on IBM that shows that, while pair programming doesn't deliver code faster, it usually deliver code with less bugs.
> I'd imagine that pair programming would devolve into a weird social game where winning strategies are either to do minimal work while one party does everything or a situation where one party does 90% of the work while demotivating their counter party. In fact - both of these strategies could be paired together!
This doesn't seem to be a problem inherent to pair programming; you'd need management or someone else to deal with those people in any scenario.
If the task is more mundane, you get someone to think about corner cases and other consequences while you code, or vice versa. This is a great way to onboard beginners, as you constantly show not only your code but your process and tools.
If the task is more exploratory, a second person might still be helpful, specially if it is someone with more experience; they can provide real time feedback on your ideas and it might be valuable.
For me, it is not just about getting the work done, it is about knowledge diffusion and code quality - I can't remember now and didn't search again, but there is some data gathered on IBM that shows that, while pair programming doesn't deliver code faster, it usually deliver code with less bugs.
> I'd imagine that pair programming would devolve into a weird social game where winning strategies are either to do minimal work while one party does everything or a situation where one party does 90% of the work while demotivating their counter party. In fact - both of these strategies could be paired together!
This doesn't seem to be a problem inherent to pair programming; you'd need management or someone else to deal with those people in any scenario.