This is based off my talk:

I assume that the majority of my readers will be familiar with the term pair-programming but for the sake of clarity, I will define pair-programming as I understand it.

It is a style of programming that has been proven to facilitate higher productivity, produce idiomatic code, reduce bus factor and improve communication and collaboration.

It is also damm hard and not for everyone. If you are uncomfortable pair-programming but still keep doing it you might be doing more damage by forcing yourself to do it than you are gaining value.

Many companies like Pivotal Labs, Unboxed Consulting, 8th Light and Living Social consider pair-programming to be a core part of their business but find themselves faced with the problem of having teams, developers and offices across cities, borders and continents.

Remote work is a reality and we have created and adjusted our tools and processes to better facilitate it.

But pair-programming often falls by the wayside and developers are provided with isolated pieces of work contradicting the collaborative nature that most our companies aspire to.

The aim of this essay is to provide you with some guidelines to becoming a better remote pair-programmer.

There is something to be said about the importance of communication when it comes to pairing and it is doubly important when remote pairing. For those of us are fortunate enough to work in an agile environment we have access to amazing people who facilitate ceremonies and activities for us. Whatever this person might be called in your team they can make pair-programming much more enjoyable and if you are that person do not forget this.

But outside of a shared workplace it becomes much harder to do that so we are going to need.

Some Ground Rules

Share Everything & Share Equally

If one partner has more control over a specific part of the process then that part will inherently suffer from lack of collaboration. By making as many things as possible accessible to both partners it promotes collaboration. And everything means everything terminals, data-stores, if you are doing mobile testing even share the device emulators. ### Be Comfortable This is more a general work thing than just a pair-programming thing because being uncomfortable has a terrible impact on focus. When you are sharing your space with someone else a lot of things can happen to make you uncomfortable whether it be bad breath, body odor, speech patterns or something as simple as elbows touching. These things can break concentration and the only way to really deal with them is to speak up. It’s hard to tell someone they are doing something you are uncomfortable with but just like in any relationship if you cannot be fully honest and open with your partner the relationship is going to suffer. ### Stop When You are Tired (Natural breaks don’t die) Pair programming is a highly intensive activity pairing for many hours at a time can be super draining don’t be afraid to take a break. One of my more memorable experiences pairing with someone was a pretty long session and as the session kept going my partner started to look more and more unconformable at some point their face turning red; Me trying to be a good partner asks them whats wrong and they says “I really really need to pee!” and I says “Wow me too”; If you need to pee, need a coffee or just want to take a breather tell your partner they probably need it just as much as you do. ### Debate with Your Partner Don’t just blindly follow whatever your partner says. Question their decisions poke at their assumptions and critique their designs. This is kinda the point by having to explain why you are doing things designs become substantially more intentional and thought through.


These are the things we strive for and appreciate when pair-programming. ### Pair Pressure When someone is watching you code you always bring your A game this is awesome and this not only produces better code but boosts self esteem because you get to show of your skills. ### Pair Negotiation A great example of this is whenever you want to take a shortcut you have to ask your partner if taking the shortcut is the best course of action. Take a guess at what the answer to that usually is. Suprise! It’s no. Having to convince your partner that the decisions you make are the right ones keeps you and your partner from making bad decisions. ### Pair Courage When writing code on your own even though you know that you are a good developer you don’t always feel 100% confident with your code. But when you had another developer that you trust working with you the code you are significantly more confident with the code that you write. ### Pair Reviews This ties into courage and negotiation but having someone critique the code you write at all times means that you don’t need to have outside code reviews because they are continuously happening. ### Pair Debugging Different people have different problem solving skills. When looking at a problem having a different perspective on the problem can often lead to much faster resolution. ### Pair Learning Sharing technical knowledge across teams is often very hard. But having developers constantly discussing their solutions to problems mentoring and cross pollination starts happening naturally. ### Pair Trust This ties in with pair courage. If a unit of work was completed by two people it is way easier to trust coming out of that team than it is to trust the work of one person. No matter how good they are.


These are good habits for pair programmers to have ### Take Breaks ### Practice Humility ### Be Confident / Be Receptive ### Communicate / Listen


Creating a consistent flow an adhering to it also helps. ### Establish Communication Open up a channel of communication with your partner and set up a backup for when things go wrong. ### Get Comfortable We went over this earlier in the article. ### Agree on Your Tools Remember Share Everything & Share Equally this also means that you need to agree on EVERYTHING you are going to be using before you start text editor, IDE, browser, VM EVERYTHING. If your partner is uncomfortable with VIM or EMACS or whatever editor you use please don’t force it on them this goes for any niche tool you might want to use pair-programming is about sharing. Not about how fast you can type or how awesome your fonts look in this new emulator. You want to be comfortable and your partner does as well; compromise. ### Profit! When everything is in place just go for it. You and your partner will figure out your own set of rules and way of doing things.

Learn about tools and remote communication

Joe Moore has an awesome talk about this

I also have a talk about this