Ways Pair Programming Can Fail
Seven things to avoid while pair programming
Marcellus Pelcher is a software engineer at Google and a member of /dev/color.
Pair programming can feel like a waste of time when it does not go well. Here is a list of things from my experience that I feel should be avoided to improve your chances of having a good session. If you have tried pair programming and you have made one or more of these mistakes, I encourage you to try again.
Failure to define tasks. It is easy to start pair programming on a project with someone without a plan. Pair programming at the project level can cause problems. It is easy to end up in the weeds arguing about direction, researching solutions, and trying to find frameworks. Before you sit down together at a keyboard, these things should be already worked out. It is best to have small defined concrete tasks that can be completed within 2 hours. A pair programming session will probably consist of 1 or 2 tasks.
Worrying about sharing credit. Worrying who will receive credit can kill pair programming before you even start. The root of the problem is that in interviews, performance reviews, and with friends, developers are asked if they “owned a project.” So when it comes to programming, they want to completely own a piece of code without the help from anyone. Not sharing credit is short sighted. I argue that working together will allow you to learn about programming, share knowledge about the software system, build camaraderie, and get more done than if the two people worked alone.
Communicating infrequently. Developers usually work alone on their computer without having to explain everything that they are doing. When pair programming, you should always try to keep your partner abreast on what you are doing. If you are typing, make sure that you check in with your partner to make sure they understand what you are doing. Don’t assume that they understand what you just wrote. View disagreements as a learning opportunity! If there is disagreement, argue your side and genuinely listen to the other side, but don’t get stuck on the disagreement. Open floor plan offices put a damper on openly communicating with your partner. Usually open floor plans have phone booths that can fit two people which can be used for communicating while pair programming.
Evaluating instead of participating. The more senior partners need to understand that this is not the time to evaluate a less senior engineer. The byproduct of the programming session may be that you can better assess the skill level of another engineer, but this should not be an objective. The senior engineer should treat the less senior engineer with the same respect as if programming with a more senior engineer. The more senior engineer should actively encourage ideas and criticism from the less senior engineer.
Showing instead of collaborating. I think this comes from a fear of not contributing their fair share to the project. So the partner tries to do as much as she can and as fast as he can to show his skill level. While demonstrating their ability, they are not taking the time to collaborate. Assessing or demonstrating skill level should not be an objective of pair programming.
Fear of exposing gaps in knowledge. A lot of developers are insecure about their abilities and how they compare to other developers. When this fear is brought into a pair programming session, this can translate into the insecure person attempting to impress the other person with knowledge and abilities. The beauty of pair programming is that neither of you knows everything, and both of you are combining your knowledge to achieve more. Pair programming allows you to help each other when stuck. It is okay not to know everything.
Pair programming all day. Pair programming is very intense. When pairing with someone, it is natural to try not to waste the other developer’s time. All social media tabs are closed, email is not checked, and phone calls are sent to voicemail. The intensity is comparable to doing a Pomodoro. Intensity is perfect for productivity and is encouraged in time windows, but very few people can sustain this for the whole day. As with the Pomodoro technique, working all day at this level of intensity is not desirable. Since pairing is intense, pairing for only 1 to 3 hours a day is reasonable.
The majority of the reasons for failure comes down to not working well with others. The key to a great session is being organized, patient, humble, respectful, and communicative. Happy pairing!
If you liked this story, please recommend it by clicking on the heart button.
Feel free to share your pairing experiences in the comments below.
Note: These are solely my opinions and are not related to my employer.
