Through my various experiences as a Developer, Technical Lead, Test Driven Development Mentor and Agile Coach, I have paired with more than 100 different Developers over the course of 10 years. As you can imagine, I’ve seen just about everything, the worst of the worst and the best of the best. Most of the people I have paired with were proficient programmers and nice people. However, pair programming can be tough, even for the best developers, and can be downright daunting if you haven’t done it before, are introverted or unsure of yourself. For those of you that want to improve your pair programming fu, I offer you my 7 Habits of Highly Effective Pair Programmers.
ProficiencyProficiency with the language and proficiency with the IDE are paramount to working as an effective pair partner. When you program with a pair partner you have nowhere to hide. All of your skills and abilities, along with your fears and shortcomings, will be on display for everyone on the team to see. This often scares people away from pair programming. To overcome these fears you must first accept that there will always be someone out there that knows more than you do. Second, you should work to improve yourself in the areas where you feel weak or unsure. Block out 30 to 60 minutes per day for self improvement for a few weeks. You’ll be surprised by the results. Finally, you must master your IDE. There’s nothing more frustrating than watching your pair partner wade through a series of dropdown menus to perform “Extract Method” when Ctrl+Alt+M is quick and easy to remember. Almost all modern IDEs have a wide range of shortcut keys for the most commonly used actions and commands. Find a reference card for your IDE on the internet and highlight the ones you think will be most useful to you. Then memorize the shortcuts and start using them everyday. Your pair partner will appreciate your mastery of the IDE and you will improve your efficiency.
CommunicationIn any relationship, communication is key. When you are pairing you are essentially in a very intense, but short, relationship. You are two people working collaboratively towards a shared goal. You must communicate well. Before you dive into a task spend a few minutes discussing the task and identifying an approach to implement a solution. You can write some given/when/then statements or actually use Cucumber or another Behavior Driven Development tool to document and clearly define your success criteria. Doing so will ensure that you and your pair partner agree on what to do and how to do it. When it's your turn at the keyboard keep your pair partner informed. You need to verbalize your thought process to let your pair partner know where you are heading and why. I try to use a verbal stream of consciousness to let my pair partner know what I am thinking and what I am doing to keep me from wondering off course and let my pair partner know where that course is leading. I also try to ask my pair partner questions to help keep my pair partner engaged and to solicit feedback and advice. For instance, after passing a test, I will often say, “What do you think?” and offer the keyboard. This is chance for my pair partner to improve, refactor or write another failing test.
Self ConfidenceWhen you are confident in yourself and your abilities you feel comfortable offering and receiving constructive criticism. Having this self confidence allows you to focus on making the criticism that you give constructive rather than using the opportunity to belittle your pair partner in order to inflate your own ego. Self awareness of your strengths and weaknesses, coupled with a confidence that you “can do this” allows you to relax and focus on your work rather than on your shortcomings. Additionally, you will be able to open yourself up to constructive criticism and you will have the perspective necessary to determine if the criticism is relevant and actionable. With self confidence you will find that you are more willingly to ask questions and try out new ideas. Your self confidence can inspire better communication on the team by setting the example that you are willing to admit that you don’t know everything and are willing to ask for and accept help. When you're self confident you don’t worry about what others are thinking about you or your productivity so you are more willing to take chances and try innovative solutions. Doesn’t this sound like someone that you would like on your team?
Self ControlWhen we were children we learned the basics of self control. We learned to take turns, to finish our homework before playing outside and to go to bed at our bedtime. But sometimes our self control lapses when we are bored, tired or frustrated. Let’s face it, our world is full of distractions: email, smart phone, internet, mobile gaming, social networks, hallway conversations, the list goes on and on. The discipline of software development requires a significant amount of mental effort and focus. So anything that distracts your attention can be a potential productivity killer. The high functioning teams that I have witnessed leverage their “team norms” or “ground rules” to help them reduce the number of potential distractions. For instance, one team made a rule that they would only use their cell phones outside their team area (see the example “ground rules” later for more ideas). You can also leverage good agile principles to stay focused. Use spikes to investigate new ideas and techniques. Add a “time allowance” to your spike story to keep you from going down an endless “rabbit hole”. When you’re working on an agile team you’re responsible for you and for everyone else on the team. That’s what we mean by the “whole team approach”. If you’re having trouble focusing you should be able to rely on your pair partner and your team to help get you back on task. Just the same, if you notice that someone else is having a hard time staying focused you need to be willing to step up and help them get back on track. Remember, you will succeed or fail as a team.
PatienceI think by now we have clearly established that writing code with a pair partner is much different than hacking by yourself all day. Your patience, or lack thereof, doesn’t usually affect others when you’re working alone. If you’ve spent your whole career as a solo “keyboard jockey”, pair programming will put your patience to the test. As a pair partner you won’t always have control of the keyboard and mouse and it is considered bad form to rip the mouse out of your partners hands. Some people have a hard time with this and have to use extreme measures, such as sitting on their hands, to keep themselves from grabbing for the keyboard or mouse. So when you get the urge to grab, take a deep breath exercise your self control and then use your best manners to ask, “May I?” Once you get control of the keyboard and mouse, you should be willing to relinquish control without a fight. Liberal keyboard passing helps keep both pair partners engaged and motivated. Some of the best athletes in team sports are the ones willing to sacrifice a small personal victory and make a pass to a teammate in order to achieve a larger team “goal”.
MannersManners in the workplace seem to have gone the way of chivalry, yet manners are a crucial part of human interaction. Programmers often forget this because they don’t have to thank their shell script for grep’ing through a log file or ask politely for their laptop to launch their favorite IDE. However, when pairing, good manners are expected and poor manners are not easily forgiven. I find it useful to start off a new pairing session by setting a few simple ground rules. If you prefer to formalize these ground rules you can work with your team to create a set of team ground rules for pairing. Some groups like the formality of a team set of rules while others prefer to play it loose and make the rules up as they go. Whichever way you go, just remember that it is necessary to have a shared understanding of how you will work together as a pair before starting to avoid confusion and hurt feelings. You might be surprised to learn the things that distract or bother your co-workers. Here’s a few example ground rules:
- Pass the keyboard liberally.
- Allow the person on the keyboard to complete a block of code before asking a question or making a comment.
- Don’t read email, talk on or play with your cell phone or other distracting behavior while actively working.
- Don’t touch the screen.