Chief Technology Officer at Advalange
Pair Programming Is Not Just for Software Tasks
Two heads are better than one is a lesson well learned from childhood fairy tales. Two pilots in an airplane, two cops in a patrol car, two persons to open a bank vault prove this concept. Pair programming works off this idea as well. In pair programming two engineers share a single workstation to produce a software code. One is a driver who does the typing. The other is an observer who conducts ad-hoc peer review and oversight. They switch roles frequently. Pair programming is widely accepted as a valuable practice in Agile development.
Nevertheless, pair programming does not exclusively belong to software development. It can be tailored to many other aspects of your work. Advalange implements this technique in several ways:
Some people have an artistic talent to present from scratch. However, many struggle to prepare a good presentation especially for a topic which is not 100 percent clear. In such a case, we usually make a skeleton of the presentation in pair programming style. Defining S.M.A.R.T. goals, deciding what to explain and what to show appears much easier when you immediately validate your idea against your teammate. When your run out of ideas, your partner may have one more idea in reserve. This raises the creation tempo.
Sometimes an analytical task is obvious. Other times the number of parameters to analyze is overwhelming. In this situation, making an analysis is like searching for a treasure chest in a misty swamp. While you are figuring out the next chain in a link your mate can quickly verify your hypothesis, make some fast side calculations or search for more information. This cuts off dead-end directions faster and keeps overall focus clearer. In addition, we often try to get the result by two different methods concurrently. Matching numbers give us more confidence to proceed to the next stage.
Like the presentation example, you can validate your thoughts and statements before throwing them out to readers. This helps to avoid context trap: you know (or at least pretend to know) what you are talking about and can skip some important details. A reader out of context may be lost and misunderstand your words. I often ask colleagues to put on a reader’s hat and provide feedback. Wearing the writer and reader hats at the same time is not easy. Some doctors may even label you schizophrenic if you do it regularly. Another benefit of pair writing is ad-hoc style and grammar correction.
Creating a comprehensive work breakdown structure is always a challenge. Sometimes a stupid mistake such as missed activity or inappropriate taxonomy results in sleepless nights and nervous overhead. While you focus on decomposing work domains to certain tasks, your mate keeps his eye on overall outcome and interactions between single tasks.
Obviously, a number of rules will make your pair work more efficient.
Rule #1: Respect your partner.
Your mate has a right to his own opinion. Educate him carefully rather than laugh at his ignorance. Remember that your goal is to achieve better results, not to criticize your fellow.
Rule #2: Trust your partner.
Never say “I don’t believe you.” If you doubt your partner, it is better to say: “I heard a different thing. Let’s double check it.” Also, let your partner finish his statement rather than interrupting him.
Rule #3: Be open-minded.
Remember that pair work aims to find the optimal way. Don’t fight for your opinion to the last breathe. You would rather dig into your buddy’s suggestions to figure out the best result. Be ready to accept that your initial idea failed.
Rule #4: Speak up.
Always comment what you are doing and why you are doing it this way. It is important that both of you talk. Do not convert pair work into a one-man speech. Do not chat. Plan short breaks every half hour to reflect. Though it seems obvious, this rule is hard to follow. You need to tune into each other for some time to find an optimal way of communicating.
Rule #5: Be focused.
Remember the goal of your pair activity. Don’t fall into brainstorming or a discussion of overall philosophical questions of your work. We usually start with writing down our goal and vision of output. This helps guide us back to the intended direction.
Rule #6: Pair only what should be paired.
Pairing each single activity is a bad idea. In the presentation example, we pair only the semantic portion of presentation preparation. Formatting it in PowerPoint is always done by one person. Use pairing when one more idea, independent opinion, review, or validation may lead to a different direction.
Pairing helps get things done well. You can’t fall asleep or go and look into Facebook “just for a couple of minutes” when a teammate is staring at you.
We at Advalange trust in pairing. In our experience, certain tasks are done up to five times faster when done in pair programming style. You may agree or not but have you ever really tried to consistently pair non-programming tasks?