Pairing at Test Double
Test Double is a software consultancy specializing in front-end web development.[87] The company doesn’t have a central office where its employees meet (at least for now), and its clients are located throughout the United States. The distributed structure of the company is by design, and the founders leverage this to gain flexibility in who they hire and what customers they work with.
As a result, developers at Test Double do a lot of remote pair programming and often coach clients who are new to pairing. But even these experts had to start somewhere.
“When I was first getting used to pairing…I behaved differently,” says Test Double cofounder Justin Searls. “I [was] out of my element. I wouldn’t use as many declarative statements, and I’d ask a lot of questions.” Justin’s confidence grew after many years of colocated and remote pairing, and he became more comfortable—especially in the areas of technology he’d mastered. “I can dive in…and shape the experience,” he says. “So the other person learns the right habits.”
Justin likes to be a good influence on his pairing partners, but he doesn’t try to overpower them. In fact, he believes it’s better when partners come together as peers. “There are lots of right ways to do things,” he believes. “It’s less important that we pick your way or my way, and it’s more important that we normalize on an approach and focus on the hard problems that actually matter.” Often, that means both programmers have to make compromises.
“For me, pairing is all about being vulnerable enough and aware enough to merge with another person,” Justin explains. And he’s found that merging as peers is particularly important when projects are at their most difficult point. He encourages developers to be honest and forthcoming about what they know, what they don’t know, and when they see things that are potentially dangerous. “Whether it’s remote or in person—at the outset of a project, when things are risky, or there are a lot of unknowns…that’s when pairing is most valuable.” And that’s also when you start learning new techniques.
There are two predominant camps of developers at Test Double: those who use Vim and those who use Sublime Text,[88] a lightweight, graphical-based code editor with some powerful features. When two Vim users pair together, the technology stack is similar to the tmux, SSH, and Vim environment we built in Chapter 2, Collaborating with Text Only, and Chapter 3, Using the Cloud to Connect. But when a Vim user pairs with a Sublime user, the Vim user usually has to give up these terminal-based tools.
Sublime Text lacks a built-in pairing mechanism and it can’t be shared over tmux. That leaves screen sharing as the only means of collaboration. The preferred screen-sharing tools at Test Double are VNC-based applications like the ones discussed in Chapter 4, Collaborating with Shared Screens, as well as some commercial products.
“The most popular is TeamViewer,” says Justin. “We all hate TeamViewer, but it’s cross-platform and faster than VNC.” TeamViewer is a software package that targets remote administration and online meetings more than pair programming,[89] but many paired teams prefer it. Justin found that by tweaking some settings, such as turning off color, he’s able to decrease latency and reduce the eye fatigue resulting from occasional lag and flickering when sharing screens. Customizations that improve the connection speed are important because bandwidth is the most critical problem Justin faces when remote-pairing.
“Bandwidth is a big problem for anyone who’s trying to accomplish this in a home-to-home setting,” Justin shares. “If I’m using a VNC-based tool and scrolling through a page, which means lots of pixels are getting refreshed, suddenly people can’t hear me or my sentences start breaking up.” It hasn’t stopped Justin or any of the developers at Test Double from remote-pairing, but they occasionally have to work around these issues—especially when they work from low-bandwidth environments. “Sometimes I want to work at a coffee shop with other humans,” says Justin, “and I have to plan my day around that. I have to pull off a chunk of work that I can do independently before I go out.” But the tmux and Vim developers don’t have this problem as long as they aren’t sharing a screen. Justin says, “The Vimmers love pairing with each other.”
Despite having two technology stacks at Test Double, the team is able to function well because every programmer has some level of proficiency with each environment. And many of the developers learned the secondary technology stack by pairing with someone who already mastered it. Sharing knowledge, however, is possible only when both parties are actively engaged in the pairing session. Justin occasionally has to remind himself of this fact. “I catch myself…reading something else, distracting myself on other stuff, and maybe even tricking myself into thinking I’m multitasking,” he admits. “[When that happens] I have to rein it in, and take a formal break.”
The need to enforce his own good behavior led Justin to make an unusual technology choice. “I have more success when I’m on my 11-inch MacBook,” he says. “I have to full-screen [my code], and I’m not tempted to go click on another window.”
Justin has learned how to recognize many cues, like becoming distracted, that tell him it might be time to change things up. “Once it’s boring to pair with somebody, or I know exactly what [my partner] is going to type before [he] types it, that’s when I stop pairing.” Justin says. “Once it gets boring, then we can have two lines of work.”
For a novice, it may be difficult to tell when it’s time to stop pairing. But maybe you don’t need to stop. Many expert pair programmers do it all day, every day.