You're facing obstacles in remote pair programming. How can you navigate through them effectively?

There are several things to consider when looking for effective tools for pair programming: 1) This is something to avoid when possible: forcing a tool to be used. The age old argument around standardizing vs. a heterogeneous toolset. I fall into the latter case because allowing a team to CHOOSE has a much better engagement percentage. 2) In our teams at DevSquads, most teams started using Discord. And because I'm from the older generation, I was scratching my head at this. I, personally prefer teams, but that's just me. 3) If you have the budget, have some ipads around. One of the most important items I miss from being in-person is a whiteboard. 4) more to say - out of room :(

One way we would share code was to work on certain common areas when pair programming and other areas when not. It kept having to merge code and we would change to one another area after we finished one. That way we had to learn the other areas.

Version control is not a solution to this. There used to be a set of tools that will allow you to collaborate in the same window like you are basically at the same screen. I know there is a plugin for the IntelliJ suite of IDE's but it was clunky the last time I checked (April 2024). Sharing screens and using your collaboration tool (Zoom/Teams/Discord/etc...) has an option to give away control. This works, but can be a little frustrating given your bandwidth.

I've never seen role-clarity as an issue. For those of us who pair-program regularly, we are constantly talking and interrupting each other when we have an idea because we communicate through code. A variation of pair programming that we use to introduce new members of the team is called ping-pong pairing: * One person writes a test, * The other makes it pass, * Back to person one who refactors, * Then we go to the beginning with the other person writing the test.

This is a general issue in any collaborative situation. How do you have constructive conflict? There are two parts to this: the technical, and the human (nothing new there). 1) Technical. Decide beforehand how to compare designs. We use the following three countable aspects of design: 1a) Duplication 1b) Coupling 1c) Cohesion 2) Human dynamics. Takes longer to understand and practice, but can be extremely effective. 2a) Psychological safety 2b) Respect - read "The Anatomy of Peace" - The Arbinger Institute 2c) Ownership and Responsibility - Read "The Responsibility Process" - Christopher Avery.

I've found that ground rules are necessary but not universal. So agree on what your team values. If you have a cross-culture team, this may not be obvious. For example - in the text introducing this problem - interruption is a bad thing. However, for many of us around the world, this is how we express ourselves when we are excited. And if someone is totally quiet, we are not quite sure how engaged they are. Instead of setting rules upfront, get really good at constructive conflict. That will allow you to incrementally build a small set of rules/boundaries that are tailored to your team. For example, if camera-on, camera-off is a big thing. Instead of complaining about it, or doing something and being quietly upset about it, talk.

Cultural compatibility of paired resources plays an important role. On a technical level it doesn't matter much but on a personal level it impacts the way of working. Pair programming isn't just about writing code, its hitting the problems in pair which involve brainstorming, cost benefit analysis and design decisions etc.