When pair programming was a fad in the early 2000s, I tried it with a coworker for a security-critical piece of code that needed two pairs of eyes on it.

It felt horrendously unproductive to have two people at one keyboard but we compared commit rates and the surprising result was that we produced the same rate of changes as working separately.

▲

pydry 4 days ago | parent | next [-]

I find it is slightly slower (maybe 20%) than two individuals alone but the quality is quite a bit higher and the effect of this higher quality compounds over time (i.e. less tech debt -> fewer bugs, faster development on future code).

Im quite credulous of Kent Beck's claim that when categorizing the last ~15 bugs on a project with pairs and singles he found that all 15 were in code merged by an individual rather than a pair.

If it were an application you could just install I think everybody would use it. It demands psychological safety though, which most teams dont have, and is becoming less common these days.

	▲	tgaj 4 days ago \| parent [-]
		It's funny because it starts to be (an application you could just install) - AI agents could work as pair programming buddies.

▲

kaffekaka 4 days ago | parent | prev [-]

Does this mean you as a pair were as productive as both of you individuals combined? Or that the pair was as productive as one individual?

Pair programming is twice as expensive so it needs to be twice a productive (quality, LOC, whatever) to make sense I guess.

	▲	jiggawatts 4 days ago \| parent [-]
		Two of us at one keyboard were as productive as the two of us separately combined. I figured this was because typically while one person was coding the other would be researching. If you’re by yourself those are serial activities instead of parallel and the total workload is the same.