It’s not as bad if you use separate chairs.

I think it depends on what your team’s goals are for pair programming. If you’re using it to just ‘complete a task,’ then yes, I think it’s likely to be counterproductive.

The better benefits tend to be

• Knowledge and practice sharing across the team
• Highlighting and aligning mental models about a project and it’s associated code
• Providing coaching/mentorship opportunities between people with different experiences and strengths (not necessarily between just senior and junior devs).

And, as with any activity, the more explicit you can be beforehand about why you’re doing it and what the expected goals/outcomes are, the more likely it is that you will find pair programming useful when it’s appropriate and recognize when it’s not.

No you’re not weird, pair programming is not one size fits all solution.

EDIT: To be clear, I still find value in pair programming, but a mandatory pair programming, for me is quite absurd. It should be organically happening, for example, a junior asking for help from senior.

Pair programming is a weird thing. It’s either an awful, uncomfortable experience or one of the best things to happen. It’s a combination of the developers and the task that determines how that particular experience will turn out.

Pair programming should be required for both new employees and for employees who have given their two weeks notice. The first allows the experienced developer to help ease newer employees into the workflow. The latter helps bring an employee up to speed with regards to the leaving employees duties and tasks.

Not at all.

Writing code is a one-person, one-keyboard, one-computer at a time task.

I don’t mind if someone watches, and I don’t mind watching someone else, but actively engaging with another person while also trying to concentrate and solve the problem in front of me is worse that counterproductive.

It completely depends on what is being worked on. In my experience, it is well suited to nebulous work filled with unknowns, and Ill suited for mundane, well-defined work.

I will say pairing is quite exhausting, just in terms of how “on” you have to be for long periods of time. Running solo you can turn off and find that flow state.

Someone else will have a completely different opinion I’m sure. Yay software.

I’ve found pair programming to be fantastic, but only when used rarely in certain situations.

If you’ve got a good rapport with a teammate and a legacy project has landed in your lap neither of you understand, I’ve found pair programming to be the fastest way to figure out how it works. As you work together, you’ll both understand different parts of it better and be able to quickly figure out what’s going on. I guess this is probably less pair-programming and more like collaborative dissection of code though.

I’ve also used it to help onboard people on a project fairly quickly. This is more tricky and much less comfortable to do, so I do my best to stay in tune with what they need from me, and tends to be me coding for a bit and them following along and asking questions. Eventually, they want to start writing some code, and a day or so of switching back and forth is as far as I’ve usually taken that. I think it’s useful to break down barriers when working with (especially new) people, to make mistakes in front of them, and build good rapport.

I’ve not used it much beyond those situations, but I’d definitely use it in these ways again.

It can vary. At its best, it’s a good way to share knowledge.

But even when it’s useful, I find it incredibly draining. I can probably only do it for a few hours before I just stop being able to manage it.

Not at all. I find it useful for certain tasks, but I’m a huge introvert and spending a long period of time with someone physically exhausts me to the point where I can’t muster coherent speech or thought. Depending on the depth of thinking required too, it’s often better for me to do that individually then bring my findings to someone else to validate.

I found it effective but exhausting. Did it for a full year, full time in an XP software shop. Burned out, needed six months in a low-pressure solo work team to recover.

Pairing wasn’t boring to me, though. Are you trading drivers regularly? Catching bugs as you go? Thinking out loud and getting feedback as you consider options? Discussing the interesting bits, like debating pros and cons of different design patterns? Parallelizing the boring bits so you’re burning through it together quickly? If you ever find yourself quietly watching someone else do menial work for any great length of time without providing meaningful input, something is wrong.

It’s a great tool for knowledge sharing, ramp up and debugging. Definitely not something that needs to happen on every story. Stuck on something or working on a weird bug? Get someone on a call and walk them through it. New team member or old susbsytem not many people understand? Pair the less knowledgeable person up with an SME for the first couple tasks so they can pick the SME’s brain while they work and get valuable context that might be lost in code or the story description.

It also doesn’t need to drag on. I find 30 minutes is best because as you approach an hour+ attention is hard to maintain. Get on the same page, learn a few things and once your making progress move to async communication.

Pair programming is a tool and only valuable if you know how and when to use it.

Pair programming is a useful tool but like all tools it can be misused.

Edit: Typo, s/paid/pair/

I enjoyed pair programming a lot for the two years I was on a project that did that. We paired every day all day, and I felt that it really drove a team dynamic where people understood the code, and the problems we were solving, and were comfortable and knowledgeable enough to have deeper discussions about technical and architectural direction.

There are some things I really miss, too. We didn’t do code reviews, because two people always had eyes on the code. We rarely ever had bugs in the code that were due to programmer error. I liked that when we came up against a tough problem there was immediately someone to bounce ideas off of, or give input if we were heading in the wrong direction. It felt very much like a team versus what I’ve experienced in my last 8 years of solo programming.

On teams where we are working alone there’s usually a lot of individual ownership over certain parts of the code. The team never feels really in tune with what everyone else is working on and what direction we are moving in. Usually a minority of the team are the vocal decision makers, and everyone else is just pulling tickets and churning out code.

With paired programming it can feel like you’re learning something new every day. You’re either paired with someone more junior, more senior, or at around the same level, and each of those groupings provide for different learning experiences and growth opportunities.

I agree that paired programming is not a silver bullet, and I agree that sometimes I felt like having two people on a task was wasteful, but overall I think it brought our team closer and made us more effective in the grand scheme of things. I miss it quite a bit!

A bit from an ops-side, but I think it applies. I think pair-work, pair-programming, pair-troubleshooting is a tool for specific situations. It’s amazing in some places, and an exhausting waste of company resources in other places.

Like, if we’re in a hard situation with many unknowns and possibly horrible consequences of mistakes. Critical systems down, situation is weird. Or, implementing config management for something entirely new. Or, trying out new code structures, ideas. That’s when being two is great. You can bounce changes you make to the system off of your copilot, so you can be very safe while being fast. You can have two opinions about shaping a piece of code and APIs. You can iterate very quickly if necessary.

On the other hand though, there are things that require deep thought. Like, I had to figure out how 4-5 teams use an infrastructural component, what’s the live cycle of the component, when to create it, when to delete it, how to remove it. It ended up being twelve lines of code in the end, but like 1 phone call every two lines of code, and an hour of thinking per line of code. Pair programming would not have been compatible with this.

Or, the third kind, is crunch work. The best way to do crunch work (besides automating it) is to just put up headphones, find flow and hammer it down. Have it reviewed later if necessary. But why would we need 2 guys following the same runbook for the upteemth time?

It’s a great tool to share knowledge and to handle critical tasks with high error potential and I wouldn’t want to miss it for that. But it can be overused in my book.

If you have two devs pair programming, at least one of them is being slowed tremendously. It should be used very sparingly and only in junior/senior mentoring attempts. Putting two senior devs on pair programming is nearly always just slashing your dev productivity.

I’ve seen devs take 3 days to write code in pair programming that either one could’ve completed on their own in 4 hours or so.