5 ms·

Just to tag along (I was going to quote and write just about all the same things), but with two developers, the HUGE value-add is codebase knowledge. If two pe

Just to tag along (I was going to quote and write just about all the same things), but with two developers, the HUGE value-add is codebase knowledge. If two people on a team regularly contribute to a repo, one person likes to work on feature A, and the other feature B, and all of a sudden, the feature B person leaves and never comes back, that will kill velocity. Even if feature A person has been doing code reviews, a code review is much different than being aware of the system and continuing to improve a feature. Now person A has to either read documentation (which is, for the sake of code writing, a 0 velocity), or take larger tours through the code to figure out why a feature is how it is, and what needs to be done. So the big question for anyone is if they want to focus on velocity/lines per day, or consistently smooth development. You can get both of those things when everyone is doing their own tickets, but that will immediately stop as soon as there is a change in your team. I don't think pairing is perfect, or mobbing for that matter, but it does give clients a more consistent/smooth experience if they are okay with paying more for quality than speed. It does take the right kind of people and the right kind of project, just like any problem and tool set.

JKCalhoun 5y ago
I'll tag along as well. (But I happen to think pair programming is a beautiful thing.) 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.
- mrozbarry 5y ago
  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.
- ineptech 5y ago
  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)
  - mrozbarry 5y ago
    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.
- gopher_space 5y ago
  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.
walljm 5y ago
I also find that pair programming can be a great way to train programmers in areas of knowledge they may not be up to speed on, to mentor junior programmers, or to just learn from your peers as they approach problems from different perspectives. i also find paring to be useful when troubleshooting or working on a hard to find bug. pairing shouldn't be the norm, but it can certainly be useful.
marcosdumay 5y ago
Well, yes, pair programming comes with a builtin permanent reduction on individual productivity. Partial knowledge comes with a builtin sporadic reduction on individual productivity when there are personal changes. What is higher depends on a lot of details. You will see a lot of completely different experiences, all real, none alike.

JKCalhoun 5y ago

I'll tag along as well. (But I happen to think pair programming is a beautiful thing.) 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.

mrozbarry 5y ago
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.
ineptech 5y ago
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)
- mrozbarry 5y ago
  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.
gopher_space 5y ago
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.

walljm 5y ago

I also find that pair programming can be a great way to train programmers in areas of knowledge they may not be up to speed on, to mentor junior programmers, or to just learn from your peers as they approach problems from different perspectives. i also find paring to be useful when troubleshooting or working on a hard to find bug. pairing shouldn't be the norm, but it can certainly be useful.

marcosdumay 5y ago

Well, yes, pair programming comes with a builtin permanent reduction on individual productivity. Partial knowledge comes with a builtin sporadic reduction on individual productivity when there are personal changes. What is higher depends on a lot of details. You will see a lot of completely different experiences, all real, none alike.