Pair Programming Solves Software Engineering Problems

Alice is a Senior Engineer at Example.com with a solid engineering team comprised of Bob, Clair and Dave. All of them have strengths and knowledge gaps, but their assignments adequately play toward their strengths for maximum efficiency.

However, pull one of those people out and suddenly efficiency breaks down and the team’s knowledge gaps are amplified.

Alice turns to pair programming. The two engineers see each other’s screens or work together at the same workstation, switching off between “driver” (the person typing) and “navigator” (the person offering suggestions). They collaborate on the same task to solve problems, create reliable workflows and engage in test driven development (TDD) for a more efficient and well-rounded outcome.

Is Your Team Like Alice’s?

Bob is a loyal five-year employee highly skilled at technologies U, V, and W, but your company has slowly been moving to X, Y, and Z technologies. How can you train Bob to use X, Y, and Z without taking time away from his family at night or on weekends to learn? How can Bob get real world experience in technologies he’s never used?

Clair has been the go-to person for deployment of Example.com for years. She’s a very talented engineer, and has just gotten an amazing opportunity to lead a new project at Google. How can you transfer all of her domain knowledge to a new engineer in two weeks, or even a month?

Dave is easily distracted. Beyond working in the noisy din of an open-air office, he spends a lot of time reading about new methodologies and technologies and shares the articles by email. Although those articles are relevant to work, he wants to focus more and sometimes has to logout of email, Reddit, Facebook, etc. to get things done. How can he focus on what he needs to get done? How can he be more productive?

How Do I Apply Pair Programming To A Team?

Pair programming doesn’t solve every problem, but it takes a major chunk out of the issues we just discussed. How?

Pairing with Bob

By pairing with others, Bob gradually builds the skills he needs to grow with the company. Engineers are fantastic at pattern recognition. Any good engineer can be put on a new project and quickly learn to be a productive member. For Bob, the key is constant and immersive on-the-job training using iterative development to identify problems and fix them.

Bob pairs with Alice, navigating in the beginning and writing more code as the day moves on. Alice writes a test or implementation whichever is easier. If Alice is writing the test, then she is designing the architecture of the code (where the code will go), and Bob just has to fill in the implementation. This is easier on Bob, who doesn’t have much experience writing tests. If Alice is writing the implementation, then Bob while writing the test just needs to stub out the interface. Bob doesn’t have to know all the idiosyncrasies and details of how the whole app is connected, he only needs to know about some small thing he just wrote. Alice can show Bob how to connect the system to make his test pass.

• Both roles have advantages for experts and beginners that paired TDD helps solve. Using the technique “red-green-refactor” (a very short test cycle that repeats over and over again) feels like a game.
• In order to spread a design pattern or engineering practice, pairing is a much better way to learn than simply listening to a lecture or reading a manual.
• If one person in the pair has experience in the project, the other person will adopt it much more quickly and with a much higher rate of success. Bob learns X, Y, and Z from Alice, and Alice learns some cross-discipline U, V, and W things from Bob.

Pairing with Clair

When Clair pairs for years with other developers on Example.com, her knowledge of the system is nearly the same as the other developers. Moreover, she would leave the company with good memories of a meaningful shared experience, carrying with it the chance she may return one day. Rather than harboring bad memories of being under appreciated or poor team communication.

• By pairing with others, the team would be aware and up-to-date on her work, and the common problems she faced. The result is eliminating some of the communication issues felt by many teams of solo engineers.
• Spreading knowledge throughout the team while pairing makes vacations, sick time or a departure far less disruptive to projects.
• The entire team gets the opportunity to learn from each other.

Pairing with Dave

He who complained about the noise and not being able to focus, now hardly has time to check his email. When Dave is pairing, he’s talking to his partner and ignoring the noise level of the office because he’s deep in another conversation. Even if a manager from another department comes by to ask a quick question – which would normally derail his focus – Dave’s pair partner is able to answer the question while Dave continues to focus.

• While pairing, team members are less likely to check personal correspondences like email or Facebook because someone else is looking at their screen.
• Positive peer-pressure keep teams focused on work when you program in pairs. In fact, usually people are mentally exhausted after a full day of pairing.

Paired Programming Questions

Q: Whose name is on the code when you check in?

A: Both names, and even a team alias, like Alice & Bob <team+alice+bob@example.com>, which, if you are using Gmail, will send an email to everyone on the team@example.com alias. Pivotal Lab’s Git Scripts handles switching pairs from the command line with git pair, and I even wrote an IntelliJ plugin that uses the same config file, which can be installed in Android Studio or any IDEA based IDE.

Q: How do you coordinate which person is typing and which person is navigating?

A: This is eventually natural based on body language. When Bob leans forward Alice knows Bob wants to type. When Alice puts her hands on her keyboard, Bob takes his hands off his keyboard. Before the pairs can recognize each other’s body language, you can say things like “Can I drive on this?”, “Let me just do one thing.”, or “Do you mind driving for a bit?”. Reasonable people avoid pointing out things that the syntax checker is also telling you, like “missed a semicolon”, try to only bring it up if the driver is about to compile. Or even better, lean forward, fix it, then lean back.

Q: Whose desk do you work at Alice’s or Bob’s? Whose computer do you use?

A: Neither Alice nor Bob own the desk or computer. They use a pairing station. Alice and Bob have their own company laptops that they can use to do a quick search or from where they can manage their health insurance benefits. But they respect each other and don’t sit at the pairing station all day on their laptops.