Pair programming is a controversial subject for programmers, and there are many myths about it. In this article we will go through some of the most common ones. If you're not sure whether pair programming is right for your team, read on to learn more!
Senior software engineering students at the University of Utah in 1999 participated in an experiment to validate the anecdotal and qualitative pair-programming results they observed throughout the industry. The test showed that when teams were made of two seniors, they completed assignments 40% - 50% faster than individuals working alone!
In PeopleWare Chapter 10, "Brain Time Versus Body Time," some statistics on the office environment are cited. They state that developers spend on average only 30% of their working hours alone and the rest of the day collaborating for a variety of reasons. Just having another coworker in your workspace has been proven to help relieve stress from isolationism.
Pair programming works well with most, but there are always some exceptions to the rule. Those who think they know it all and have an excess ego or strong personality can really wreak havoc on a team dynamic, if not avoided early in the process of pair programming.
The approach of pair programming allows two minds to work together towards problems solving, which often leads to better, more creative and more sustainable solutions.
Two people with complementary skills will always come up with a better solution than what any one of them could produce on their own. Two experienced programmers are able to fill in each other's knowledge gaps and everyone has some areas where they lack expertise, so it is always worth bringing on an extra pair for the project team!
"Pairing" is about better quality code and solutions for the project, which benefits both teams. So desired personal success leads to team-successes as well - if an individual's goal was simply their own achievement then it would mean nothing without any benefit transfer getting through on behalf of others who work alongside them (in sports terminology). It needs to put effort into pair evaluations but those are valuable feedback loops with management as well as other coders; they'll all thank you once things start going smoothly again!
The navigator is doing more than syntax checks. They must hold the roadmap and stay between lines on a winding road while constantly assessing overall design with an eye for potential improvements from other team members who may have different ideas about where best to go next. The driver implements their latest agreed-upon idea, but also helps brainstorm new ones when necessary.
For exemple, for all the issues, a navigator is good at communicating intent – the what, not the how, and uses inclusive language (“us” and “we”, rather than “I” or “you”) as much as possible while at it, so the driver is invited to revisit some of the motivations behind intents they might not necessarily agree on.
This (wrong) idea comes from a desire to be in the “flow” or zone. The Zone is often thought about as an ultimate destination where you can lose all sense of time and space with productivity at its peak - but it turns out there are some downsides too!
Losing context or flow can happen with a 15 second interruption. A partner will help you get back into the problem quickly and efficiently, returning your attention to it in no time at all! Studies show that when individuals are helped along by their colleagues, they get right back on track within 10-15 minutes (Pragmatic Thinking and Learning).
Pair programming also means that you'll get less interruption than if you were to work individually at your desk.
Pair programming is a controversial topic with many myths surrounding it. In this article we've debunked some of the most common ones to help you make an informed decision on whether or not you want to try it out for yourself. Which one of these popular myths about pair programming have been holding you back?