I have been pair programming for four months now. Although I have always been intrigued by this Agile practice and have theoretically understood its potential benefits, I was quite apprehensive about its effectiveness, never having tried it myself.
In the past months though, I have had the chance to experience pair programming firsthand, so I’d like to share my observations, lessons learnt and some do’s and don’ts.
Pair programming, by definition, is a collaborative activity between you and your ‘pair’. For effective collaboration, it is important to have a clear understanding of the goal and a general plan of action for the day’s tasks. The most common mistake is to immediately jump into programming without adequate thought or discussion on what needs to be done and how. This leads to confusion and waste of time. So the first step is to spend a few minutes making a roadmap for the day, before you begin coding. Here is a useful checklist to help get started:
- What are we working on today?
- What do we plan to achieve by the end of the day?
- What was accomplished yesterday?
- Are there blockers that need to be addressed first?
- Are there personal constraints to be considered? (one of you needs to leave early, the other has a meeting to attend etc.,)
One of the things I had some trouble with in my early days of pairing was that my pair and I would often break for lunch, coffee etc., at different times. We ended up wasting time each day, waiting for each other during these breaks. So I decided to discuss my break plan (lunch, training, stroll etc.,) with my pair so that we could arrive at a common break schedule that worked for both of us. This way, we avoided waiting for each other and got more productive.
Don’t continue to work when your pair is not around. Don’t be that over zealous programmer who is too excited to stop work even for a few minutes when your pair has stepped away from your desk. This is an extremely insensitive behavior and can prevent your pair from effectively collaborating with you. So unless both of you have agreed otherwise, do not continue to work on a task individually, in the absence of either one of you.
It’s not Monopoly!
Keyboard monopolization – this is perhaps the number one complaint among pairing partners. Even if unintentional, this can get very annoying. If either one of you has more experience or story-background than the other, you may be tempted to hog the keyboard causing your pair to disengage completely. Next thing your pair will be opening up their own laptop and starting to check emails.
This may also happen when one of you is too shy to code (for example, your pair has just joined your team, your organization etc., ) In such cases, it is even more important that you consciously let them drive the work by turns. Sure, it can sometimes be difficult to restrain yourself. When you see your pair struggling with ‘extract method’ refactoring manually, and you think that a slight of your ‘defter’ hand could accomplish the same task within a split second. But remember, we are all new to tools and technologies at some point. Also, we all have our own individual style of learning and working. So, do avoid constant ‘helpful’ hints when your pair is at work. Do not interrupt. Do not cough keyboard shortcuts when your pair seems to be a bit slow. Instead, take a deep breath and watch them work (or learn, as the case might be). Encourage them to work at their own pace. A word of encouragement will go a long way in making your pair feel more comfortable working with you.
And if you are on the receiving end of this behavior – ‘Speak up!’ Tell your pair that you need some time to get more comfortable. There is no need to be apologetic. Don’t let your shyness or keyboard-discomfort become your excuse for not stepping up. Learn to switch driving seats with your pair and function as a peer.
Like it or not, pairing is a social activity. It is your responsibility to embrace good social etiquette towards your pair. Constant interaction and collaboration with another individual can often get very stressful. It will take a lot of discipline and really good communication skills to make it less nerve-racking for the both of you. This is where most of us make mistakes, mostly because of years of mental conditioning and bad habits. Here are some tips that might help:
- Communicate and share a plan (as already explained above)
- Share your thoughts frequently. If you are stuck at a problem, step back, face your pair and tell them what you are thinking. Ask them what they think should be done.
- Respect your pair’s opinions and skills. Pairing must remain a democratic process whereby skills and experience are used to collectively create something , and not become a competition where another individual is made to feel inferior. So engage your pair even when at times they may be feeling inhibited. And if you are the one on the receiving end, speak up. It is your responsibility to contribute.
- Be courteous and polite. Ask for your pair’s opinions, and do not impose yours. Make suggestions. Discuss and argue over a point but don’t insist on having the last word, always. Even when you disagree with your pair, do so politely. Let your pair have an equal say in the matter.
- Time-box all discussions. In other words, do not drag discussions for too long. One of the things that has often helped me is to say to my pair, “I don’t mind discussing this but since this is really a minor issue, let’s time-box it for 5 minutes”. This way, we can remain focussed and on-course all the time.
- When your pair is coding, it is your job to take notes on things you think will need attention later. Do not interrupt or flag issues immediately. For example, if your pair has used a method name that you do not like for some reason, note it down. Do not break the flow. Once your pair is done with the typing, bring it up and discuss.
- Vocalize frequently what was just done, what is being done and what is going to be done next. I know this sounds funny but here are two examples of situations where this helps me:
- Catch errors and gaps if any, prior to checking in code: As we review each file before checking in our code, I say (out loud) things like, “ …So in this file we have now changed this function to throw an Exception…and then in this other file, we have added another constant, and then, we’ve refactored to alter the variable name here, here and here…but wait, why did we add this new constant here?”. This vocalization helps the pair of us to remain very alert to possible loopholes even before we check-in our code.
- Pre-empt and analyze expected test results: While testing a piece of code manually, I take a moment to discuss the change we’ve just made, and pre-empt how this would affect the test results. Voicing out loud “…So we’ve changed the signature of this service to pass in a timezone value…that means when I click here, I would expect to see the product details with the correct time zone, right? …” This pre-emption helps to improve focus and effectiveness of the testing activity which can otherwise feel very repetitive and boring.
The point is, the more you communicate, the better you get at it. There is of course the risk of over communicating and annoying your partner and I hope I am not doing that :-)
- Mind your body language. A closed body language sends a negative message to your pair. Be mindful of that. Make sure you are always slightly turned towards your pair, always maintaining an acceptable social distance, even while typing.
There is a certain minimum standard of personal hygiene you must observe. Enough said.
Pairing with another programmer is like wine pairing. If attempting, it must be done just right.
And it’s all about sharing and learning . It need not always be predefined, uniform, or standardized. We all have our individual quirks and styles. Pairing should not suppress this. So let your own unique personality shine through. If you prefer a dark theme for your IDE (and if your pair is OK with it), go ahead and use a dark theme. If you like humming a peppy number while you wait for the code to compile, hum away. See if you can’t get your pair to drum on the desk in accompaniment.
Pairing is a great opportunity to learn something new about your co-workers. So love/hate other people’s unique quirks, thought processes, opinions, dress sense, eating habits…anything, but do not diss any of it. We all need to express ourselves, feel comfortable and make coming to work everyday worthwhile.
Pairing is fun but not a substitute for solo programming
Man, (they say) is a social animal. But to some of us, pairing can feel like this.
Personally, I need to work alone a few hours every week. It’s a different world altogether and I enjoy my solo flights very much. If you are like me, try to fit in a few hours of solo programming into your routine. This will help improve your own zen and your pair’s lifespan.
Besides being a useful productivity booster, pair programming (when done right) can prove to be a rewarding experience.