Pair programming with two brains and one keyboard

Programming is usually not a team sport. I like my headphones, my lights a certain way, and my space! But pair programming is the software development technique in which two programmers work in tandem at one workstation - ugg, I know. While at first blush it would seem to be more time consuming, Roger Neel, CTO and Co-Founder, Mavenlink says it’s actually a much more efficient method of programming when used correctly.

He mentions a few of the benefits of pair programming include:

• Focus. Both programmers actively discuss the challenges and problems they’re working on while also minimizing outside distractions.
• Fewer mistakes. It's more deliberate than solo programming, it results in far fewer mistakes to fix later on.
• Improved on-boarding and training. Pairing new employees with experienced programmers helps new hires get up to speed quickly.

We recently caught up with Roger to get some insight into this somewhat unorthodox approach to programming - something that I think by proxy, most of us have done in a small way without even realizing it. And when implimenting it as a standard practice for your dev teams - at the right time, can prove to be a huge win for your team.

ADM: When were you first exposed to the concept of coding together on one workstation?

Neel: I was first exposed to pairing in college during the project phases of much of our Computer Science coursework. It was the only way to get the work done in a timely enough manner where both partners felt good about what we were turning in. After joining the workforce, I was surprised not to see pairing as a standard method of engineering.

ADM: When and why did Mavenlink adopt it?

Neel: We started pairing from our very first line of code. We were seeking a partner in 2009 to help us launch Mavenlink, and we found Pivotal Labs. It was part of what attracted us to working with Pivotal. I had finally found what I was looking for! They taught us how to pair effectively in a professional work environment with larger teams and we’ve been doing it ever since.

ADM: Was it an easy decision? Why or why not?

Neel: I saw the impact of it right away. We were building Mavenlink using Ruby on Rails, which was relatively new at the time, and I didn’t know Rails yet. Through pairing, I was able to pick it up pretty quickly. As our team grew, I noticed how easy it was to onboard new engineers, and we saw how sharing code ownership can really change the game for team collaboration and code quality. It helped us move so much faster in the early days because everyone knew the whole code base and could easily make mutually agreeable decisions.

ADM: What are the business benefits of pair programming?

Neel: It's important to note that it's not just about pairing itself. On a team of say four, five, or eight engineers, pair rotation is key to getting the most out of pairing. This means engineers changing pairs every day or two - moving between different tracks of work and seeing most of the new code the team's developing. The context switching can feel disruptive at first, but for teams that push through the early pain, the benefits are substantial.

Broader contextual awareness among the team leads to better decision making. Shared knowledge of the code means if one person is out sick, or leaves the company, we can still make progress on any given feature. All the pairing sessions are also teaching sessions, so our developers learn from each other as they rotate.

This all leads to one of the biggest benefits of it we’ve experienced - much lower engineering ramp times. We feel that we can ramp an engineer into our code base and practices quicker by using pairing, rotations, and context sharing than in a more traditional solo environment. There are many ways to give new engineers support and context, but none as direct as pairing.

ADM: What are the business drawbacks?

Neel: Pairing will affect which candidates are attracted to your culture. For some candidates, pairing is a filter out. It’s important to establish that up front and not waste anyone’s time. Obviously, the engineers who join Mavenlink are excited about pairing, and we find for them, our culture is a big draw. So I’d say pairing is neither a headwind or tailwind when it comes to recruiting, but it is a discussion point you need to position with candidates appropriately.

A day spent pairing can be more tiring than coding solo, so we need to be mindful of not burning our team out on pairing. We end up pairing about 70% of the time, and our developers appreciate the solo time to explore on their own.  

ADM: Do you think it's use is gaining in popularity?

Neel: While it’s still a minority practice, pairing has definitely gained broader acceptance as a legitimate way to develop software. There’s fewer of the naive, “Don’t you go half as fast?” reactions, and there’s more recognition of pairing’s benefits. More companies have been integrating some level of pairing into their processes.

Interestingly, we’ve seen a lot of the increased mindshare being generated by the coding bootcamps. Many bootcamps have a pairing-based approach, so their students are used to it from day one. At first, they think that’s just the way it’s done. We talk to a lot of candidates who paired at bootcamp maybe three years ago, then stopped pairing when they got their first job, and are excited to talk to us at Mavenlink because of the chance to pair again.

ADM: How does it benefit collaboration? Is there a direct effect on workplace culture?

Neel: Pairing absolutely has an effect on collaboration and culture. Our product development team is a highly collaborative team and the engineering environment almost sounds like an outbound sales floor. There’s a huge amount of discussion going on all the time during the workday about the product and the code. We’ve seen this culture also impact other areas of the business and has certainly shaped the core values of the company, inside and outside the R&D team.

ADM: Does it attract great developers? If so, why?

Neel: Many great developers are drawn to pair programming. We've been pleased with the talent we've been able to attract through our pairing culture.

As to why - for many developers, it’s just a more enjoyable way to build software. Engineering is about the joy of making something work. The best pairing sessions make that joy a shared experience.

ADM: What are some of the common pitfalls of solo programming? Does pair programming address those pitfalls?

Neel: There’s a lot of different ways to build great software, some involving pairing and some not. We don’t believe that pairing is the only answer. A favorite quote of mine is that “software engineering is a team sport.” We find that pairing does address pitfalls of a solo engineer continuing to grind away at a problem, beholden to dates, without being able to get the help they need to make the right decision. There are plenty of instances we can point to where pairing has helped make better decisions up front to ensure successful, on-time delivery.

ADM: Do all engineers at Mavenlink pair program?

Neel: Yes.

ADM: What are some examples of when pair programming isn’t the best option?

Neel: We’ve found that pairing is the right tool for many jobs, but not all jobs. One common theme I’ve heard from others is that “we pair on the hard stuff, but solo on the easy stuff” - I feel that’s not really a good practice. Hard or easy from whose perspective? Does a problem that seems easy at face value become difficult once the complexity presents itself? Where we find solo time beneficial is during quick explorations to find the complexity in a problem (e.g. spikes), technology choices we could make, and then reporting the findings back to the team during daily standup or in a planning meeting. We also allow our development teams leeway to make decisions on where there’s enough shared context in the feature that a solo developer can tackle the issue.’

ADM's final thoughts

It was interesting to chat about something that is seemingly not so well known, at least in the term used. But ironically the more I learned, the more familiar it all sounded. To me the biggest takeaway from this conversation was the awareness of the benefits "true" pair programming offers.

While pure "pair programming" is not as widely adopted as it could be, around our development studio (Moonbeam Development - shameless plug), our version exists in the office shout-out, "hey can someone come in here and look at this, I need an extra pair of eyes.."

About Roger Neel

Roger Neel is a software expert with over 12 years in the industry, Roger is an advocate for technology solutions that deliver business value. He brings expertise and best practices insight across industries in the areas of content management, knowledge management, project management, resource management, project accounting, business intelligence, and social networking applications. As CTO, Roger directs the product and engineering decisions of Mavenlink.

An accomplished web app designer, Ruby on Rails engineer, and thought leader in agile software development, Roger has worked with and advised a range of companies: from newly-formed startups to nationally recognized products and brands such as Apple, 3M, and Bank of America. He helped advise new product development and engineering while part of the Sales and Partners team for integrated knowledge management platform InQuira (acquired by Oracle in 2011), where he met fellow Mavenlink co-founders Ray Grainger and Sean Crafts.

Outside of leading the Mavenlink engineering team, Roger dedicates his time to mentoring startup founders and software developers. He is passionate about sharing his insight and advice with others when it comes to navigating the critical cross-section between business and technology. He was an early adopter and an advocate for the Lean Startup movement and pair programming principles. Roger carries a B.A. in Computer Science and Economics from Cornell University.