Debunking the Myths of Pair-Programming
During my transition at my new job, I found myself having to consistently ask to pair with others as part of ramping up on the code base. In fact, even past the ramp-up, I found myself still having to ask others to pair program. Many are familiar with pair-programming, but what I’ve found is that many would rather not pair for the following reasons based on their experiences:
Pair-programming Myths
- Pair-programming is exhausting/not worth the effort.
- Pair-programming is best for ramping up new developers.
- Pair-programming slows me down from what I need to do.
- Pair-programming is okay for some bugs, but not others.
- Pair-programming is not for me.
Pair-programming Realities
- Pair-programming is an acquired social-skill that takes practice for others to learn to work with people.
- Pair-programming significantly shortens the time it takes to work on a problem if done right.
- Pair-programming is beneficial for all levels/experiences.
- Pair-programming creates better cohesion for your codebase and encourages a transfer in practices and knowledge amongst engineers.
What is Good Pair-programming?
Kent Beck, who originally coined the term, described two programmers working at different levels of abstraction. The idea was later expanded to the metaphor of navigator and driver:
In this metaphor, the driver controls the keyboard and focuses on the immediate task of coding, and the navigation acts as a reviewer, observing and thinking about more strategic architectural issues. As in pair-programming, the driver trusts the navigator to guide the driver to the destination while keeping the driver in check (Are you driving too fast? Did you take the wrong turn?).
Most importantly, those roles change constantly, usually over something like “No, let me show you what I mean”. If you’re doing pair programming right, your screen should be covered with greasy finger-marks by the end of the day.
What Pair-programming is Not
To continue on the driver/navigator metaphor, an ineffective caricature of pair-programming has one programmer firmly in control while the other sits quietly, doing little. This is the source of the misunderstanding that pair-programming does not add value. Such scenarios are common when working with more experienced programmers, or even between genders or ethnicity (Choi).
The Mechanisms of Successful Pair-Programming
1. The Rubber Plant Effect
People may criticize that pair-programming can slow you down if you’re paired with a novice programmer. Constructivist theory states that knowledge cannot be taught in the standard hypothetical bubble of passive information absorption, but must be built by learners during the learning-processes. According to the constructivist point of view, learners build understanding recursively from previous knowledge and experiences, with which new mental models are created (MIST 2015).
Constructivist theory is supported in the ecosystem via an open and collaborative framework where unique work is created and a community may relate other pieces of work with each other through commentary and challenges.
Experiments by Linda Hermer-Vazquez and her colleagues on integrating knowledge about geometry and color showed that adults perform as poorly as young children when their linguistic abilities are occupied with a verbal shadowing task. What they found was that adults perform as poorly as young children when their linguistic abilities are occupied with a verbal shadowing task.
The results of Hermer-Vazques show:
- When we hear the right question, our brains make the necessary information available and the language module can then perform rudimentary inference and draw obvious conclusions.
- Even as an expert, questions are often asked in such a way that you’re forced to deconstruct assumptions already accepted and in the process, a deeper understanding is gained.
The first mechanism would therefore lead us to predict that programmers who chat about their programs should be more productive and that those who pose occasional deep questions would be far more productive.
2. Pair-programmers Notice More Details
How many times have you stared at the same lines of code for hours until you have realized a parenthesis is missing or a word has been misspelled? If we don’t know what to look for, we can stare right at it and still miss it. Research on change blindness shows that shows that people are remarkably poor at detecting changes from 2D images in laboratory conditions to real-life situations substitution one person for the other. In other words, we lie to ourselves all the time. Humans naturally are prone to be less-detail oriented; we remember the general ideas of a memory, but we’re liable to fill in missing details with what our brain assumes to be correct.
In a psychological study conducted by Kimberely Wade and Maryanne Garry, 20 subjects were exposed to a false childhood event via a fake photograph and imagery instructions. Over three interviews, subjects thought about a photograph showing them on a hot air balloon ride and tried to recall the event by using guided-imagery exercises. Fifty percent of the subjects created complete or partial false memories.
In pair programming, two people won’t have the same prior knowledge or categorization. One will spot certain aspects faster and the other different aspects faster. The person who isn’t typing code always pick up typos faster; likewise, another person can keep the driver in check for semantics or fault in design. To keep views and perspectives fresh, pairs must swap partners, as spending so much time together will eventually have programmers start thinking the same way.
Mechanism 4: Fighting Poor Practices
One advantage of pair programming is pair pressure, the feeling of not wanting to let your partner down. The code-and-fix style of programming is most often used by novice programmers (also often used by experienced programmers) in which programmers write some code they hope will do a particular thing and then run it to see what happens. If it appears to work, they press on with other code, without systematically searching for flaws. When the code fails, which is often the case, they tinker with the code haphazardly until it appears to work.
Behavioral psychology offers a plausible explanation for this style of programming — which involves learning to perform some action spontaneously and reinforced with reward, known as operant conditioning. Such conditioning is common with training animals with sporadic rewards. As long as there is a reward before a certain behavior diminishes, then that behavior can be restored to full strength. Code-and-fix programming is effectively coders putting a slot into the machine in hopes of success.
Slot machines are known as the most addictive form of gambling, and similarly unpredictable rewards form code-and-fix programming can be equally addictive. To resist this “addiction”, we can fall on pair-programming to agree in advance how to write and test code, much like the process that is encouraged in whiteboard interviews — understand the problem being asked, gain clarification, and mock a solution, all before starting to write your code.
4. Knowledge Transference & Judging Expertise
When two people work on an issue together, you’ll have 2 chances for referencing a person on specialty information needed. Likewise, gauging the expertise of another programmer’s knowledge can best be done with pair programming. It isn’t enough to talk with someone about programming to judge expertise. A surprising of candidates completely fail to produce even the most basic evidence of the knowledge they claim. In fact, this is a common issue seen across the industry as seen in Why a Good Java Programmer is Hard to Find, You are Not Paid to Code, etc.
A weak version of this technique is standard practice in programming interviews. You must work on a problem with them to gauge their expertise. There is a surprising of candidates, no matter how plausible they may sound, completely fails to produce even the most basic evidence of the knowledge they claim. These candidates also seem blissfully unaware of their own lack of expertise. Meanwhile, the most competent suffers from consensus effect.This happens for the same reason: it’s hard to accurately assess others’ competence, so the most competent have no reason to believe they’re extraordinary — unless they work closely with another programmer on the same problem. Swapping partners is the best way to find everyone’s niche in expertise while simultaneously transferring the knowledge.
Conclusion
Pair programming is not something you get good at overnight. However, the best code bases I’ve seen are at companies that encourage pair programming. Growing together is what makes a project successful, so brave the unknown and give it a shot.
Sources Cited:
- Wray, Stuart. “How Pair Programming Really Works.” Computer.org, IEEE Computer Society, 2010, https://www.computer.org/cms/Computer.org/ComputingNow/homepage/2010/0110/W_SW_PairProgramming.pdf
- Eileen Fordham, Halley Freger, Amanda Hinchman-Dominguez, Alexander Mitchell, Daniel Rebelsky, Victoria Tsou, Earnest Wheeler, Zoe Wolter, and Samuel A. Rebelsky. 2015. MIST, The Mathematical Image Synthesis Toolkit. In Proceedings of the 46th ACM Technical Symposium on Computer Science Education (SIGCSE ‘15). ACM, New York, NY, USA, 599–599. DOI: https://doi.org/10.1145/2676723.2691878
- Wade, K.A., Garry, M., Don Read, J. et al. Psychonomic Bulletin & Review (2002) 9: 597. https://doi.org/10.3758/BF03196318
- Hermer-Vazquez, L et al. “Sources of flexibility in human cognition: dual-task studies of space and language.” Cognitive psychology 39 1 (1999): 3–36.
- Choi, Kyungsub. (2014). A comparative analysis of different gender pair combinations in pair programming. Behaviour & Information Technology. 34. 1–13. 10.1080/0144929X.
