Maybe this is a misconception or misrepresentation of pair-programming, at least compared to my experience. One person isn't supposed to be doing both. You're either navigating/explaining or driving/doing. Pair programming isn't about one person doing everything and another person watching and trying to keep up. It's about communicating and sharing an understanding, like a realtime/interactive PR description/review while writing. Of course there are times where one person will simply say "let me write this out and discuss after" and go at it for a short while, but it should be the exception rather than the rule in settings where it worked best for me.
Perhaps it is, but I'm not really going to entertain someone saying they tried it and it didn't work, when all they did was work their own screens/keyboards sitting side-by-side (or remote) each with their own ideas and not really sharing in the process, except to interrupt and annoy each other.
no I actually get it, I think like most fads, it seems to work great for really trivial things or for debugging. I have myself used pair programming in those cases.
I just can't imagine using it for serious work. navigating/explaining? I know neither the science I'm trying to code nor the code I'm trying to write - I'll write code to explore the data, I'll have a hunch, I'll wonder about something and I'll go find that one paper I came across 10 years ago to check - I don't see what code the other would be writing while I'm trying to figure that stuff out.
Totally agree. I wouldn't say it's well suited for research or research-heavy work. In those cases, I'll do research on my own and reconvene later or another day.
