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

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

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.

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. 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 always felt that pair programming is more useful on early stages of a task, where there is enough doubt about implementation details and discussing them is worth.

This way it felt more of a meeting between two persons discussing details first, while testing them live to check if we were on track second, instead of programming first and discussing second.

By the time we stand on the screen without talking too much we just stepped aside and separate the task if needed.

Any other kind of forced pair programming feels wrong, either because the task was already planned enough to no create enough discussion, or because it was small enough and the discussion was not worth. I’ve found myself on situations where “we needed” to make a task in pair programming and was dull as you say.

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

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

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

I’ve had useless paired programming sessions and great ones. Definitely depends on the person and the problem.

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.

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.