When I first encountered and heard the term pair programming, I was amazed at the possibilities. It takes programming to a communication exercise rather than logic puzzle, and gets two seperate minds working on the same problem. Living in the location that I am in, pair programming was not an option unless it was remote. Remote pairing seems like an exciting and productive way to work.

I have come close to what you might call pair programming while helping my wife learn Ruby. She has worked on some small programs with me in the background giving advice and steering her in the right direction. And she has once sat in the non-drivers seat and asked questions as I worked a problem. However, this did not prepare me for remote pairing.

Yesterday, I took the plunge and paired with another person remotely. I am still very very new to ruby, rails, vim, tmux, git and collaborative programming. It takes a lot of patience and understanding in that first session. It also takes a lot of preparation, of which I had done little.

The experience was extremely new and I had no idea of what to expect. So much so that I didn’t have any defined questions that I was looking to have answered. This should have served as a clue I needed to put off the session and do more homework and planning.

The Pains:

• tmux is a great tool, however keybinding and scrollbuffers are hard to overcome.
• Google+ Hangouts and screensharing are slow, but essential to vercoming the small setup issues
• Custom vim and tmux keybindings are also a hinderence. Less is more.
• In your first session between two unfamiliar people, expect tool problems to be the big issue and take most of the time allotted.

Suggestions

• The first time, pair with someone who has done it before, lean on their experience.
• At least one person on the pair, should be familiar with the chosen editor, and with tmux or the screen sharing software.
• Have a specific goal at the onset of the pair. Small goals will help foster the sense of accomplishment needed. No goals or large goals can make the experience frustrating.
• Set a time limit and stick to it.
• If stuck on a particular problem, table it for later. Pairing is about collaboration, not two people googling solutions while remoting. If it is a showstopper, then agree to stop and agree to come back later once you both have had a chance to attempt the solution.
• Pair programming is different than just writing code. You are in constant communication and that is more exhausting than coding by yourself.
• Each of you has their own strengths. If you allow one person to drive and one to talk and stick with that strategy you can learn almost by osmosis. It also presents the opportunity to ask “Hey, what was that you just did?”

Overall I learned quite a bit about what not to do, and how to prepare. I would add that if it had not been for the patience of my pair, I would have had little chance to learn what I did.