Whether you like or dislike pair programming, pair programming is becoming more common. Some companies encourage it, while others made it part of the work culture. Thus, it is important that you familiarize yourself with pair programming and how to make the most out of it.
1. Know Why You’re Pairing
What exactly are you hoping to get out of pairing in a particular case? Are you trying to minimize bugs? Are you trying to maximize output? Are you bridging the gap between different expertise or levels of experience?
2. Figure out How You’re Pairing
Before touching the keyboard there are some things you need to make clear with who you will be pairing with. Compare how each of you likes to work and decide on a way how you will work as a pair. For example, do one of you like to plan everything out and research before coding or do you like to just dive in and learn by doing. Figure out what you and your pair will do about bugs and errors. How will disagreements be resolved?
In addition, to the big picture aspects, you should also figure out the smaller details. You and your pair should agree on a formatting convention for your files, variables, functions, and etc. How should the navigator bring something up to the driver? Does the person point at the screen or take control of the mouse or mention the line number for a chunk of code? How zoomed in or out the screen should be? How often to take breaks?
3. Commit to a Driver and Navigator Role
This is one of the most important aspects to pair programming that many developers have trouble with initially. At first, pairing seems like having two people to do the work of one. So, it becomes tempting to split up the work between you and your partner. You should not do this because it leads to negative productivity.
Working in parallel leads to a bad end most of the time. You’ll end up having to explain to each other what you’ve done. Also, you won’t know the other person’s code well enough to spot bugs, which results in a lower quality output. In addition, you would not be working directly together in ways that will teach and grow your skills, which defeats the purpose of pairing.
Driver Role
When you are the driver, you are making the decisions (code) of how to implement something. However, this doesn’t mean that your pair (navigator) have nothing to contribute. So, when they ask questions or offer a different approach don’t immediately become defensive. Instead, trust that they have a good reason and hear them out and discuss it.
Navigator Role
When you are the navigator, you should keep your hands off the mouse and keyboard unless necessary whether you are pairing in person or remotely. For example, taking the mouse to highlight a section of code in question after you try to bring up the topic with your pair. As the navigator, your job is to figure out the higher-level order logic, look out for potential bugs, research documentation, and most importantly be a fresh pair of eyes. If you know and have the right solution, don’t just grab the keyboard and start typing. Instead, you should explain it to the driver, which then he or she would implement it if you both agree.
4. Switch Role Often
For developers, being in the driver’s seat is definitely more fun. After all, you get to code and not watch another person code. However, you shouldn’t hog all the fun and give your pair a chance to be the driver. Even if your partner doesn’t request to be the driver, you should offer it. They might feel that it is rude to interrupt you midway.
5. Expect and Accept Correction
A big advantage to pair programming is that you are combining two sets of experience. This means you should expect your partner to question your decisions. When they do don’t become defensive. Instead, discuss with them why you made those decisions and hear out their opinions and make changes if appropriate. Sometimes, your partner may be the quieter type and in such a case you can start the discussion yourself and invite them to interrupt at any moment.
6. Be Willing to Lose
There are going to be times when you and your partner will have different opinions. You guys should talk it out and try to arrive at the best decision. That means swallowing your pride and accept the other decision if it is the better one.
There will be cases where there is no clear winner. In such a case, it might be best to pick one. After all, you can always refactor the code if you feel that you guys went the wrong direction.
7. Be an Encourager
You probably like to be praised when you do a job well done. Give the same consideration to your partner. Call attention to their contributions. Take the opportunities to build your partner up in front of the team. Talk about your partner more than yourself.
I hope this post was helpful to you. If you found this post helpful, share it with others so they can benefit too.
Do you practice pair programming? What is your opinion on the effectiveness of pair programming?
To get in touch, you can follow me on Twitter, leave a comment, or send me an email at steven@brightdevelopers.com.