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

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.

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.

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’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 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.

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.

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.

I hate it. I really enjoy programming, and don’t enjoy social niceties. And I definitely don’t enjoy someone looking over my shoulder all the time.

So that leads to 2 situations: I’m programming, but someone is looking over my shoulder and stopping me constantly (or doing nothing), or I’m watching someone else program and constantly frustrated that it’s not me.

Even during an emergency I’m often better off just doing my thing solo, and the other person using their own methods to investigate and fix the problem. Chat is still available to share information and progress without it being a constant annoyance.

The only thing I think it’s really good for is learning to program, and unless the people are the same level, it’s probably only good for 1 of them.