Pairing is great for some tasks, like higher level design and whiteboarding sessions. But when it comes to implementation (coding) time I really dislike it.<p>I think ultimately, at the end of the day, I expect and hope that every human I work with is a competent, solid individual contributor and does not require a co-driver to produce meaningful work.<p>I definitely see the value in pairing for imbalanced situations (junior and senior, new engineer and tenured), but such sessions should have the goal of getting each person to operate independently, hopefully sooner than later.<p>Pairing just for the sake of pairing is an encroachment on many things I love about software (the ability to think about a problem deeply and quietly, the ability to work independently, the ability to check my Twitter feed as often as I damn please). I’m really glad the pairing fad seems to be dying down in general!
> Forgetting it’s a skill<p>> Pair programming is a skill which must be learned.<p>> You will not be good at it at first, but consistent practice will yield improvements.<p>> Don’t give up after a difficult first experience. Don’t assume experienced developers are automatically good pairing partners. Don’t expect to be good without practice.<p>> Consider reflecting with your pair or asking for feedback after each session. What could have been better?<p>In my experience (pairing on and off for about 12 years) - this is the biggest thing people misunderstand about pairing. You're not going to be good at it right away, and the team isn't going to benefit right away. It's an investment that pays off in months not days.<p>That being said - I find that requiring my team to be <i>good</i> at pairing, but not that they pair all day every day, is sufficient. It means that they pair when it's appropriate (onboarding, larger design problems, early stages of a project, etc) and they don't when it's less appropriate (fleshing out an implementation, exploring a new idea, mundane updates).<p>We find that if we pair all the time, especially on things that don't benefit from pairing, it exhausts us. Pairing is a useful tool, but it can be equally dangerous if overused and cause people to resent it.
> Sit so that the monitor is between the two of you.<p>No. Use two monitors that are mirrored or with screen sharing, so that each person can sit comfortably centred on their own screen.
I work at a place where we do exclusively pair programming (a software consultancy). A project always has at least one pair.<p>Each workstation has a computer, 2 monitors, 2 mice and keyboards. When someone can't be at the office then we sometimes use Tuple, and it's a great tool, unfortunately still only works on Macs.<p>Pairing works for us because it's more efficient than working alone, less bugs and better thought out design, faster spread of knowledge about our tools and the project in general. I joined a year ago and hadn't used Java or IDEA, pairing helped me learn all of it very fast, compared to if I had to work alone and struggle with learning all of the new things.
I'm curious where the pair programming religion came from. There was certainly a time when it didn't exist as a concept. I for sure don't remember anyone suggesting that it would be cool if two folks sat around the ASR-33 and took turns to hunt-n-peck on the keyboard. Perhaps it originated in the brogrammer movement?<p>Anyway, the sibling article says:<p>"A pair of programmers tends to produce better code than someone working alone."<p>Let's assume this is true (I'm reasonably sure it's false). If one programmer can type code that's at quality N, then add a second one to look at what they're typing and perhaps you can say that quality will be >N since the second person might spot errors made by the first. But we just used TWICE as many people to write that "better" code. I expect there are industries where this burning of resources makes sense, but most of the time it won't regardless of the improved code quality achieved. We could write 2x the amount of crappy code and most organizations would opt to do that.<p>If we're pairing up at the terminal to teach/train/transfer knowledge, that makes much sense and has been done since the ASR-33. Also sometimes it helps to have two or more people stare at a debugging session together to crack a gnarly problem. Designing at the whiteboard has been a thing since Von Neumann and Turing (chalk board...)<p>Programming however, isn't a thing you do in pairs, imho. It's creepy and weird.
We tried out Live Share (collaborative editing) during pair and mob programming sessions. I enjoyed it a lot - made it feel like a multi-player game.<p>Sometimes it did allow for the equivalent of a pair programmer taking over the keyboard rather than explaining how to solve a problem.<p>I’m curious if anyone has any Live Share patterns / anti-patterns.
Forced pair programming is an antipattern. It's a recipe for burning your best workers.<p>You had better hope that the oft-touted knowledge transfer benefits of pairing are real, because you are going to have to deal with the turnover.
I used to be diametrically opposed to pair programming back when I was a junior developer. These days I often find myself parachuting into troubled code bases and trying to fix technical debt while under time pressure to launch a new feature. I often see things that, I can only imagine, were written by some junior dev trying to impress their boss by just hacking something together and throwing it over the wall. More and more I wish that code had been written via pair programming, where the other (hopefully more senior and judicious) developer could have, perhaps by only their mere presence, prevented the hack dev from doing what they did.
I'd be interested in such a write up for remote pair programming. Being remote the likelihood is much higher that the navigator loses focus and answers emails or slack instead.
Switching roles more quickly might be the solution. We've tried tools like mob.sh, but the most efficient way seems to be using something like VSCodes liveshare. Unfortunately half of my team uses Intellij and the other half VSCode.
I don't see pair programming as a disruption to the individual mind of the single programmer.<p>Then I believe something is wrong in culture of the organisation. It should definitely not be enforced but encouraged.<p>The reasons I believe that is because the human psychology is also based around success and praise from our relations.<p>The benefits you get from sharing thoughts and possible options to a challenge can hardly, imo, be bad.<p>Pair programming has taken place in my career, in cultures that encourages a pace to get work done, in a manner where quality is measured by how well a team works together and how well the team is capable of understanding eachother - but as a team.<p>I also believe that if you cannot explain in words, how you would go about solving a challenge, then it's premature to start coding on it. Then you are moving to fast.<p>Pair programming is like any other thing. It should be applied when necessary and not be enforced on 80% of the work because it's perhaps only valid for the hard 20%.<p>I have really thought about making a pair programming service for years, where people can connect and program as a pair, for the hard parts.<p>Good discussion
I'm not sure about pair programming. I never really understood why we stop at two people. Why not have 3 or 5 people working together? And indeed that's what we do when for example doing system design and it's incredibly useful.<p>Writing mundane code in pairs sounds like a brute force solution that should be solved by training, higher quality code scanners or other code quality tools.
I've done plenty of pair programming informally when one of us were stuck on some hairy bit of code and needed another pair of eyes and some extra brain power to get to a solution but I've never done it in an ongoing formal context. What I've always wondered is if you get the doubling of productivity required to justify having two resources working on the same bit of code? Certainly in blocking situations you can get a huge multiplier on productivity (I'm including quality and correctness in my definition of productivity) but lots of code is mundane stuff that just needs someone to push through and knock it out. Can a pair get the mundane stuff done in half the time of a solo developer?
The greatest anti-pattern is <i>mandating</i> pair programming.<p>The greatest pattern is explaining your goals and seeing if <i>other</i> people's goals align with yours.<p>The chances of that conversation resulting in 'pair programming', is 0%.
How about just not having a navigator and driver. Having gone through a "wing-it" approach to pairing extensively, it really is an awful experience for those who hate having to fight for control.
The entire guide just worth a read, even if you’re an experienced pair. Lots of great patterns.<p>We do full-time pair programming in my teams, and this guide is part of our “starter pack” for documentation.
I would quit if I was forced to pair program. Pair programming is <i>loved</i> by incompetent software developers because they can hide in the shadow of more competent developers. That's my experience anyway. YMMV of course.
Can someone point me to a great work of software that was written by two people simualtaneously collaborating like Lennon and McCarthy writing songs? I never see any evidence given that pair programming is a better way to code.
“Allowing unproductive distractions” is one of the major reason why I think home office is fundamentally less productive, no matter how much people have come to like it. Pair programming through screen sharing works fine on a technical level, but you can’t turn off children.
I haven't physically paired in years. Even before the pandemic I'd often be screen sharing with someone across the table from me. We'd just be positioned where we could see each others' faces and our own screens.<p>These days it's all fully remote. And that's worked out incredibly well since my team has gotten more and more geographically dispersed. The few that were before are now always in the loop.<p>I haven't done it full time in a while because my responsibilities other than implementation take too much time.<p>I'm old in my team and when I can, it works well for me. I share my experience, keep software focused, etc. The younger, high performers teach me new tools and tech. The fresh folks learn more how to think and do work from us. Stuff like that it's not just about making something work, but making something maintainable. I probably teach as much backspacing through a "clever" idea I had, than by writing anything. That and how to break a problem into chunks. Then reevaluate that and make it clean.<p>Pairing is also great for the more ops side of things. I think in a lot of ways you get even more bang out of it there than programming. Have 1 person do the work and a newer person improve the docs as they go. Then flip for the next iteration, with the new person driving and the experienced one helping and tweaking docs. Call out places where automation could replace procedure and get them in the backlog to be prioritized later. The same pair can pick up those stories when they come back around.<p>I have experienced some of the pains of this list. I worked with a guy who I joked "painted" code. Lines just growing and shrinking like a horizontal EQ. It was dizzying and unpleasant. I often just checked out and pointed out missing braces every once in a while.<p>Same guy brings up an issue not mentioned here for physical pairing: make sure you bathe. Ugh.<p>Also, make sure you're rotating teammates. Sticking in 1 pair can be nice if you like the person... for a while. But it can ruin a friendship if you do that for months.<p>I think the real keys to success there are in luck and management's hands. Make sure you have a mix of maturity and skill sets, and have engaged curious people. Slackers and, uh, "dim" people drag everyone's morale down more in an environment like that. I've lost those teammates and seen team productivity grow. At the same time, it's hard for a team full of people with little to learn from each other to stick with it. It's more engaging when you're teaching or learning or ideally both.
When working alone remotely from home, I simulate pair programming with a methodology I call "The Stranger". I sit on one of my hands until it becomes numb and tingly, and then it feels like somebody else is typing and moving the mouse!