I love pair programming but remotely, with only audio. Live share in vscode, and jetbrains has their own version. The one keyboard paradigm is gone and you can work in two parts of the same code base at the same time. It’s not an all the time solution in my mind, but I frequently see higher quality code coming from these sessions with way smoother pr reviews. Just my two cents, as an introverted former pair programming hater (pre pandemic in the office).
Against Pair Programming
81–90 of 180 posts
Re: Against Pair Programming
#82Ha. 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…
Agreed. Sounds like someone who pays for lines of code.
Re: Against Pair Programming
#83Pair programming can be powerful with the right people and the right problem. It's a situational tool that can speed up progress in certain cases. Sometimes diving deeply into code is scary and having someone else right there can provide a feeling of safety that's conducive to making real progress. Also, sometimes programmers can have complimentary skills that can help them solve hard problems together on the spot. P…
In general I agree. I've found pair programming to be immensely beneficial and productive for some cases.
I wouldn't go so far as to say recurring sessions are always bad, but I do think that not all tasks benefit from having a pair work on it.
When I have been very attuned with my teammates in terms of the system we were building and how we were building then pairing sessions became much less valuable on work that was very low novelty and was some iteration of a well-established pattern.
Re: Against Pair Programming
#84Ha. 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, 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.
Re: Against Pair Programming
#85Reducing 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…
Agreed, what a disappointing argument. Personally I love pairing -- I've learned a lot from pairing with others over the course of my career. Earlier in my career, seeing how others worked went a long way towards improving my own workflows. I think there are some valid criticisms to be made against mandated pair programming. In some circumstances, such as thinking through a solution on the fly to a subtle bug or chal…
Personally I've turned down jobs at places which require pair programming because it drains me. There's no way I can sustain it for very long.
I'm happy to do it occasionally to transfer knowledge, but it slows me down massively because it totally changes my thought processes when I'm constantly aware of another person there with me.
I wonder how significant the effect of mandating it is on the personalities you're able to hire. Many of my by far most productive developers have been introverts like me who'd likely not to consider jobs in those kinds of environments.
Re: Against Pair Programming
#86Ha. 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…
> I'd say it's more like having a second pair of eyes while you're doing a tricky reversing maneuver. 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.
I don't think that is good analogy. Driving race with driver and navigator are in completely different then anything related to programming or even pair programming.
That analogy is just yet another way how to shut up people who dont like the process.
Re: Against Pair Programming
#87I'm pair programming ambivalent. A lot folks like it. I mostly don't, but I enjoy collaborating more broadly, and sometimes a pairing session can be truly invaluable when the task at hand is right. I think it has many benefits in that at least knowledge isn't entirely siloed with 1 contributor. It's not the silver bullet to solving wider system awareness problems though. >> Not to mention the coveted flow state that…
I really enjoy a pairing or mobbing session, but I haven’t figured out a good way to integrate a key part of my process.
I usually attempt an aggressive reshaping commit history as I find it allows me to re-evaluate and improve the code, but it also allows me to craft a PR that can be understood commit by commit (and even split out unrelated work to prevent big PRs).
I appreciate reviewing small PRs that tell a story (and revisiting a nice PR years later for context), so I put a lot of effort into it.
Often it’s an exercise in tedium that doesn’t really suit 10-15 min handoffs when you’re stuck deep in a rebase and it gets tougher when the commits are all “WIP,” but the biggest thing that bothers me is that doing so often clobbers the other devs contribution if the commits have been sufficiently remixed, and I want their contributions recognized in the history.
Re: Against Pair Programming
#88Ha. 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,…
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.
Re: Against Pair Programming
#89Pair programming easily achieves the >2x speed boost though. The driver focuses on the technical details of writing high-quality code, implementation, proper variable naming and so on whilst the navigator keeps track of the overall task, provides extra short-term memory, spots silly mistakes/typos, focuses on business logic etc. So instead of one programmer juggling too much and stalling, getting bored/frustrated, lo…
It definitely does not work that way for me. No matter which role I am, a lot more effort goes into following what other person does then when I do it by myself. This is like saying that two people hugging while each is using just one leg are faster, because they have to focus only on one leg while walking.
Re: Against Pair Programming
#90Earlier quoted context omitted.
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,…
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…
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.