Pair Programming — Bootcamp Style

My name is Darren Littlejohn and I’m a student at LEARN Academy in their 16-week Fullstack React/Javascript Web Development Bootcamp. As we wrap up the curriculum and prepare to move into our internships, I was asked to share my experience with Pair Programming.

I thought when I went to coding bootcamp that I’d learn how to program by myself in a corner somewhere. Headphones on, tucked inside a nice cubicle. I’ve worked alone on my computer for many years and have never had the experience of collaborating on tech stuff. The LEARN Academy Bootcamp strongly emphasizes the concept of Pair Programming. When I mention Pair Programming to friends, they usually say something like, “Oh, two people program at once.” True. Yet it’s more than just two programmers sitting around a computer, swapping Star Wars trivia between writing sessions. Pair Programming is deeply rooted in theories of product development and best practices to achieve results.

What is Pair Programming?

Let’s look at the official definition, then I’ll share my experiences.

Wikipedia:

Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently.

Agile is a process of software development where, “Solutions evolve through collaboration between self-organizing, cross-functional teams utilizing the appropriate practices for their context.” The project is guided, not run by the project manager, called scrum master. The scrum master then manages the direction of the project without micromanaging individuals or individual features of the project. Teams and individuals organically participate in the the scrum:

Scrum is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques.

From this emerged the concept of pair programming. Two developers sit at a computer where one drives (types the code) and the other navigates (makes suggestions, looks for mistakes). That’s the what.

The How

While reviewing, the observer (navigator) also considers the “strategic” direction of the work, coming up with ideas for improvements and likely future problems to address. This frees the driver to focus all of their attention on the “tactical” aspects of completing the current task, using the observer as a safety net and guide.

The pair roles can be switched every 25 minutes or so, in a system called the Pomodoro Technique as a way to reduce distractions and improve productivity. The idea is that two pairs of eyes are better than one. What might take one programmer several hours to bang his head on can often be solved by two in a fraction of the time. Caveat: often, but not always.

As mentioned above, I went into this thinking I’d be able to silo myself from other people and focus solely on writing code all day. I wasn’t really sure I could work well with others. Here’s what happened. We have 12 people in our cohort. Some are have more tech experience and/or aptitude than others. Those with less experience can set a pattern and have a difficult time staying grounded in the project. One reason is that the program is a total immersion experience. We study multiple, complicated technologies that constantly shift and evolve. Bootcamp, aptly named, is too much from Day 1 and doesn’t let up. That makes it tough to find ground to stand on before moving on to the next topic. So you have that level of intensity in the program, which affects the pair programming process. At least that’s how it is in the Bootcamp context. It may be better or worse in a production environment.

I worked with everyone in the group at least once. Some of us paired organically more often. Sometimes it’s really good and you learn a lot together. Other times it can be frustrating. The person you’re working with might not like to communicate or prefers to make small talk instead of coding. Maybe they’re quicker on the uptake and need to develop a little patience with the other partner. Two super sharp individuals can work very well and get a lot of code completed, but for two people who are struggling the process can move pretty slowly.

Part of the challenge, at least at first, is that it’s hard to get to know someone’s temperament, thinking process and work ethic. You can’t always choose your partner so it’s best to learn how to work through any blocks. Some programmers like to push ahead without sharing their rationale. Others have a hard time articulating but are skilled at writing functions. If one pair is strong and the other less experience, one becomes more of an au pair rather than a pair. The process is meant to be a collaboration, where each party will pause to take input, consider other viewpoints and switch roles from navigator to driver and back. Sometimes we need a sounding board to clarify things such as process what’s our process here, what are we trying to do, how can we research this, what code can we look back on to see what worked.

In the course of eleven weeks I’ve determined that I really get a lot of benefit from pairing. In fact, I’ve come to rely on it. I might stare at a problem by myself for 45 minutes where another programmer can look over my shoulder and say, “You forgot a curly bracket there,” and voila. The code runs. I find that I can often contribute a very outside the box thought process, ask purposeful questions and suggest ways to research.

Pairing all day every day can be exhausting though. Sometimes we need a break to work alone, maybe for a day or two or just long enough to take a walk and get away from the computer screen. With all of these tools and orientations in mind, the process of software development can take different forms. So far, they’re all interesting to me. I realize that this process is not accepted across the board. Some shops use mob programming with 5 or more developers working off a 60″ monitor. Others let the process happen organically while others may put you in pairs and rotate you out so you can get exposure to different facets of the application you’re developing.

Some things that I’ve tried to make the pair process go smoothly are listed below as suggestions. You might find some of these helpful if you’re just starting with pairing.

• Ask questions. If the pair is ahead of you, ask them to share their thought process. If behind, make sure you don’t leave them behind. Ask them to explain what you just did or if it makes sense. Help each other.
• Listen. Carefully.
• Read the code. Slowly.
• Don’t grab the mouse! Ask permission before you take over the monitor. This keeps tensions down.
• Take breaks. Use Pomodoro.
• Pause for the occasional chit chat. Ask about the person’s likes, dislikes, or other things to help form a real human relationship.
• Work hard. Study a lot. Make sure you’re doing your best.
• When it’s beer-thirty, it’s beer-thirty. Relax!