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.
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.
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 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.
What is higher depends on a lot of details. You will see a lot of completely different experiences, all real, none alike.
I’ve always liked the rally racing driver/navigator analogy for explaining pair programming. It tends to go better if you generally follow those roles when doing it too.
That analogy is just yet another way how to shut up people who dont like the process.
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. But, going into "this makes sense, because two people make sense in rally racing" is neither of those.
Why rally racing and not any of the other races where competitors are alone? Why not soccer team for that matter? That seems closer to development then any vehicle racing anyway.
There seems to be two directions of analogies here. One is arguing from subject to analog. “Programming is like rally car driving so we should act like they do.” Pretty crummy argument. I’d have no answer to your “why rally car?” question.
The other direction is explaining from subject to analog. “Strong-style pair programming is like rally car driving.” There’s much less of a claim here. I’m just saying they have enough shared attributes that I can map how they’re similar and you may find that useful for understanding. So why rally cars? Because that’s the context that has the most similar method as the one I’m talking about (not that it’s the most similar context).
In the latter case, the claim of fitness is separate from the analogy. “This method is useful. It’s like one rally car drivers use”. There’s no “because” in there.
It is fair to guess that nearly no one here ever sat in rally car. We know it has navigátor, but we don't actually know what navigator exactly does. And I genuinely don't see many similarities. It seem to be more about split second decision making in situation where you need to speed up or slow down toward turn.
Did you read the link I posted? The essence of the idea is you have one person who takes physical action, makes small decisions and take orders. That person is called “driver”. You have another person who makes larger decisions and gives orders. That person is called “navigator”.
The dynamic I just described is true of rally car driving and strong style pair programming. It’s not true for most pair programming or most other types of driving.
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 people, others will never like it. It worked for me because I was kept on task. It may have slowed down the top performer but that person appreciated the company. Overall I think it made our team of 8 at the time more productive than they’d have been with separate assignments, and it really helped with team cohesion.
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.
I'd not done it much in the past but recently seen it done more and participated more - each time it's been useful. I paired to deploy some work, and having both of us work together was really helpful as we could talk through issues we were seeing as we went and it taught me more about infra & them more about the project.
When it comes to novels and art though, there's a focus on producing one persons imagined work, edited and helped by others. When it comes to programming, particularly in a company, there's a problem to solve.
Is it common in other fields of engineering to say that only one engineer can work on a problem at once?
> Individuals do these things all the time.
Individuals code alone all the time too. What I'm commenting on is the idea that programming together with someone is terrible.
Well one thing you need to consider is that most software is not written in small, artisian batches but at scale. Pairing is one way to promote doing development and all the things you mention at a greater capacity than the individual.
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 developers. I have ADHD and pairing is not great for me. My attention doesn't work on demand, for any topic I choose. I fit chores in between engaging tasks to keep things going, creating the illusion of doing one thing after the other, but I'd rather not be interrupted or judged with either and to a neurotypical person this behavior might seem erratic and confusing.
Sometimes it helps me to have an external force help direct my focus.
It honestly feels like torture to me.
Switching tasks lets me reset from this state well enough, so I consider it essential coping.
What's great, though, about getting some work ready, creating the PR; and then waiting .. Minutes? Hours? ... days? who can tell? For a response.
if you're wanting "productive", that isn't it.
Yes, the system's productivity is not about maximising the uninterrupted productivity of person A, or of person B either.
Sending a whole pile-up of PRs isn't a great solution either.
yes, this is important: for a senior / expert, knowledge transfer, i.e. showing someone else what to do, often is much slower than "just doing the work by yourself"; but that does not make its value lesser.
If you optimise for productivity today, you might regret it tomorrow.
> Aren't code reviews and design reviews 1-to-1 as well? Or worse, n-to-1.
I think PR reviews can be a resource for other engineers on the team to learn from beyond just the PR author. Granted, I think pair programming can probably deliver these lessons more effectively since you can have a live conversation about it and clear up any confusion there.
>> In addition, most of these alternatives be done asynchronously.
> And this is better, because...?
I don’t know the author’s feelings here, but I think this makes some sense in the context of the rising popularity of remote work. It isn’t necessarily a given that you’re in a similar time zone to your teammates.
I’ve also been interested in the topic of async work throughout the pandemic, with companies like Gitlab and Doist as examples who also evangelize the practice. I’ve pushed for some of those async practices on my team at work but feel like we’ve had mixed to little success with them.
So I agree with your skepticism of “async is better”, even if there was some reasoning provided.
> Pair programming can pick up mistakes before they propagate, which increases velocity.
Notice how it's "reduce bugs" twice with some other hand-waving qualities thrown in. Even if you have some solo developer write code with a bug, having another developer go through and fix it is a time saver over PP for all the code that was not error prone. Then we have the metric mixing issue of measuring developer code quality, over time, when mixing more than 1 person in a task.
> And this is better, because...?
Because you can avoid paying for idle time. The most common quality of pair programming team (considered productive or not) is watching one member waiting to see the other write out the function and functionality that was already agreed upon. Developers already do this when they have a tough problem. They invite others to talk and look through the code, ad hoc.
Pair programming has already been tried by a multitude of teams across decades and it does not produce results that have driven it's widespread adoption. End of story.
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 "output" you have to include quality (fewer bugs), improved codebase knowledge (bus factors etc), improved team cohesion etc.
> Pair programmers tend to give feedback that's more appropriate in a design or code review.
What's his evidence? Why is it more appropriate there (after the code is written) than here (before/during)?
> For the pairs that follow this, the only feedback that's left tends to be bikeshedding or stylistic, both of which kill velocity.
That's, um, bullshit. Pair programming can pick up mistakes before they propagate, which increases velocity.
> It's like having a backseat driver.
I'd say it's more like having a second pair of eyes while you're doing a tricky reversing maneuver.
> Alternatives like code reviews, design reviews, and general documentation are much better 1-to-n ways to share knowledge instead of 1-to-1.
Aren't code reviews and design reviews 1-to-1 as well? Or worse, n-to-1.
> In addition, most of these alternatives be done asynchronously.
And this is better, because...?