One more, though this is hard to explain analytically: shared language about and mental model of the codebase. If four people build a platform working separately, they will each come out of the project with subtly different ideas of what the platform is and how it's organized.
That's kind of subjective and I don't think I could prove its usefulness on graph paper to someone who isn't convinced, but I think it's real and significant. (and hence I'm curious if people who have mobbed a lot agree)
I have this exact issue. My client has a few teams working on related products on different platforms and languages, and when we discuss bugs, I'll use a term that will almost immediately get a "oh, that's not what you mean, because thing x in this context means thing y." For example, iOS sandbox applications vs testflight applications vs sandbox purchases. Both applications use sandbox purchases, so just saying "sandbox" is ambiguous or can often cause confusion.
Oh, I should have mentioned, I mob program every day at my current job, and pair programmed every day at my previous job, and both were very successful and enjoyable jobs.
Re:Against Pair Programming
by gopher_space on Friday February 18, 2022 @01:28PM
(#30389290)
My biggest gripe with pair programming is that people are already too close to me when they're at their own desk minding their own business. I love working on closely related or even intertwined projects, however. It'd be interesting to work on a really good pair team for a little bit, see what a "perfect example" looks like.
Code reviews in real time, in situ.
"White board discussions" in real time, in situ.
Learning how someone else codes/debugs.
These are all worth the price of pairing up engineers in my mind.
If we're talking agile development, I would love it if all engineers could get paired up for at least one sprint a year. Especially less experienced or new to the team engineers. I suspect it will be the pairing experiences that foster the most professional growth.