Pair programming eh? Knowledge sharing with each other, discussing different approaches on how to solve problems. This is the intention but, does it always end up being that way? No. Why not?

I think it is some of our idiosyncrasies.

Not everyone is compatible for pair programming however, there are do’s and don’ts we can follow.

Do’s

• Time to switch It’s important that the driver (person typing) is not in control for too long otherwise, it can become easy for the observer to lose focus. As a junior, I am always keen to take control too so, taking a backseat for a bit too long can get tiring.

• What the hell are you thinking? Explain your thoughts. It is not easy to tell especially if you have come up with a bright idea and it hasn’t hit me yet (almost always the case). It helps the observer follow what you are doing and not left trying to figure it out. It’s not good to do this after you’ve implemented your bright idea either because by the time you do explain it I’ve already tired myself out so much trying to figure out what you were trying to do. Now that you say it I have to process that new thought and it gets exhausting.

• Enough space and visibility You know how you need to adjust your mirrors and seat in a driving exam (and every time you are about drive) before you start driving? It’s pretty much the same thing with pairing.

Allocate proper space for both people and make sure it is easy to see what’s on the screen.

• Patience When both the observer and the driver are out of ideas for a problem and are thinking it is important for both of them to not feel any pressure so they can think freely. The comfort comes with knowing each other more and having spent time pairing for a certain amount of time (or can also be character and/or experience).

Don’ts

• Try not to interrupt When the driver is explaining something it is probably best to not interrupt and wait for them to finish. As a driver it can be hard to explain the reasoning behind what you are doing as you are doing it. It makes it even harder if you start questioning it or interrupting as the observer. Even if it is incorrect in your opinion the driver should still have a chance. You can always discuss after the driver is done explaining and/or implementing then discuss a possibly better solution.

• Hands off Taking the keyboard off the driver before his turn has finished is a no no. Explain it to the driver and let the driver type it for you this way they will learn. Even if it is like teaching a kid something, be patient. Try using line numbers, pointing out examples in the code or whatever you feel may help.