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.

▲

bluecheese452 4 days ago | parent [-]

This feels a bit no true scotsman.

▲

karmakaze 3 days ago | parent | next [-]

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.

▲

exe34 4 days ago | parent | prev [-]

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.

I'm sure it works great for yet another CRUD.

	▲	3 days ago \| parent \| next [-]
		[deleted]
	▲	karmakaze 3 days ago \| parent \| prev [-]
		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.