I like sharing ideas with someone while we're both coding together. I think "pair programming" works a lot better when two people sit down and work together on different parts of the same problem.
Example: Alice is building the front-end for a product search page. Bob is building the product search APIs on the back-end. Alice and Bob working together can share immediate feedback on each other's designs and implementations, and work out any tiny ambiguities that weren't covered by whatever specification they previously agreed on.
I think some of the best software dev experiences in my career have come from this style of collaboration.
Ha. I dislike pair programming as much as anyone, but this argument is really weak. It doesn't sound like he has actually had much experience of it, and is just judging it from the outside. But let's go through some points: >Since we are employing two programmers to do work on the same keyboard at the same time, the output of pair programming must be greater than 2x the output of a single programmer to make sense. In…
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,…
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.
Ha. I dislike pair programming as much as anyone, but this argument is really weak. It doesn't sound like he has actually had much experience of it, and is just judging it from the outside. But let's go through some points: >Since we are employing two programmers to do work on the same keyboard at the same time, the output of pair programming must be greater than 2x the output of a single programmer to make sense. In…
Asynchronous workflows should be the default. Interruptions are almost universally bad, so being able to fit a code review into your work day whenever you want is much better. Even if you have a fixed meeting, you might've just started to get productive on something else, or maybe there's something that actually needs to be handled synchronously, like an incident. It also is a lot more pleasant for neurodiverse devel…
> Asynchronous workflows should be the default. Interruptions are almost universally bad,
What's great, though, about getting some work ready, creating the PR; and then waiting .. Minutes? Hours? ... days? who can tell? For a response.
Ha. I dislike pair programming as much as anyone, but this argument is really weak. It doesn't sound like he has actually had much experience of it, and is just judging it from the outside. But let's go through some points: >Since we are employing two programmers to do work on the same keyboard at the same time, the output of pair programming must be greater than 2x the output of a single programmer to make sense. In…
Well said. I would add to that: pair programming is a unique opportunity to create human connections between teammates, which is very valuable in general, and even more valuable in a remote setup.
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 exper…
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…
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.
Reducing pair programming to numerical economic value like that is quite absurd: "Since we are employing two programmers to do work on the same keyboard at the same time, the output of pair programming must be greater than 2x the output of a single programmer to make sense." The point of pair programming is to teach and learn from each other, not to maintain some pointless productivity metric. Utterly ridiculous. I d…
In the context of a job where somebody is paying you to develop software, the entire point is to produce economic value. That’s why you’re getting paid. Your entire job reduces to economic value.
There’s an argument that “teaching and learning from each other” produces more economic value in the long run, but you reach diminishing returns pretty quickly on that.
>>> Since we are employing two programmers to do work on the same keyboard at the same time, the output of pair programming must be greater than 2x the output of a single programmer to make sense. Not at all. Two programmers working on the same project at the same time is already slower than one programmer working twice as long because these two have to communicate. And during pair programming, the communication is s…
> Two programmers working on the same project at the same time is already slower than one programmer working twice as long because these two have to communicate. And during pair programming, the communication is sped up.
I actually disagree pretty strongly with this.
If you have two programmers working on the same project at the same time, you can split up the project along a pre-negotiated interface ahead of time. It takes some amount of communication to do that, but you don’t have to communicate about every single line of code the way you do with pair programming. In fact I’d say my #1 problem with pair programming is the added communication overhead.
Please read the article all the way through before commenting. Your other points are already addressed.
I think davedx read the article, davedx even copy/pasted/quoted it, and I totally agree, the author is being overly simplistic in the analysis made. And on the other hand, somehow the author of the article passes asynchronous code reviews as good thing. I mean, that is THE problem that pair/mob programming is solving, imho.
I don't understand... what is wrong with asynchronous code reviews? From my POV code reviews are the solution to the pair programming problem.
Please read the article all the way through before commenting. Your other points are already addressed.
I assume you mean this part: > While pair programming might achieve some goals as a pedagogical tool, there are more time and cost efficient ways to share knowledge between team members. It's a very hand-wavey dismissal - "yeah, that doesn't work... NEXT!". I've enjoyed both sides of the learning process in pair programming and implying that documentation can cover everything that can be learned like that is, in my e…
Sure, he's not going into extreme detail, but then again I doubt that's the point of the post. I found myself nodding in agreement as I read along, but that's probably because I've been in the trenches so long. I've done it both ways and I've never seen pair programming as having any significant advantages, but rather having drawbacks in most (though not all) situations.
> In that case explaining why you like anything is a way to shut people up who don't No. It is just that specifically agile has a way to responding to people who dont like something with very very handwavy explanations that feel good, but dont really mean anything. Explaining why you personally like something is entirely different kind of communication. Explaining why you think something works well is also different.…
> Why not soccer team for that matter? That seems closer to development then any vehicle racing anyway. Perhaps unintentionally, a good analogy for traditional software teams. Eleven players, one or two stars, the other players mostly looking good because they can pass the ball to the top players. In the end, all analogies suck. Pair programming is a pretty unique situation in the workplace, it works great for some p…
It was not unintentional. It does fit better and has no pair programming.
But, the non star soccer players in competitive teams are significantly better then what you imply. And do way more work and have way more knowledge.