If you’re a programmer but you haven’t tried pair programming, we suggest you buddy up and use this guide to get started as soon as possible. We, Ethan and Nate, have been pair programming for about two years now, and it has lead to faster debugging, better code, and more value to our company.
We may have accidentally become one person in the process, but the benefits are worth it.
What Is Pair Programming?
Pair programming — or brogramming as we like to call it — is a method of developing software that involves two people working together at the same computer. We use pair programming because it fits with our belief that two heads are better than one. Measure twice, cut once. Fail fast and succeed faster.
(Pear programming, on the other hand, is writing software to compete with another large company named after a fruit.)
Why Use Pair Programming?
Business managers might have a knee-jerk reaction when they first hear about pair programming: “It’s more expensive to pay two people to write one piece of code! They should each write their own code and get more done.”
Although at first it might seem like paying two people to sit at one keyboard is less efficient, we’ve seen an increase in long-term benefits:
- Best practices: Coding practices become standardized organically.
- Quality: Code quality increases as two smart people work on a solution together. Together we can bounce ideas off of each other to reach a better solution than either of us would have reached individually. This ultimately results in fewer bugs to fix later, and less time spent hunting and untangling problems.
- Reduced silos: Multiple team members are aware of how parts of the code were implemented as well as any specific challenges that arose for that feature. The result is that more team members are capable of quickly updating functionality without running into the same problems that may have been solved when the code was first written.
9 Tips for How to Win at Pair Programming
These tips can help you get the most out of pair programming:
- Hire the right programmers. The hiring might not be up to you, but in reality, a good culture for pair programming actually starts at the hiring process. The programmers at BitLoft are friendly and collaborative by nature — if not a little crazy — so programming on a two-person team comes pretty easily.
- Use your proximity! Regardless of how you feel about open office layouts, they really do support pair programming. Because our chairs are on wheels, it’s easy to roll along the laminate floor when summoned to a co-conspirator’s desk.
- Use your words and communicate. We use Slack, an instant messaging tool, to work on projects with partners that are working remotely. Slack allows for voice calls, screen sharing, and webcam use, but the programmer’s ideal habitat of a dark basement isn’t conducive to video conferencing much of the time.
- Know your role. Because keyboards aren’t big enough for four hands, in pair programming there is a driver who types and mouses, and a passenger/reviewer who provides input and throws a red flag when the driver misses a semicolon. The driver and passenger program this way for at least an hour and then switch. Having a laptop helps the passenger research solutions or refer to other sections of code to speed up progress.
- Don’t be afraid to use brief pairing sessions. Because our team is small, our interactions are spontaneous and ephemeral. We get a lot accomplished with short sessions.
- Make pair programming a routine…. We plan to make this a routine, scheduled practice as our teams and codebase grow. This will help to onboard new team members to get them up and running quickly. Through pair programming, we’ll address any knowledge gaps that would slow down new teammates in their first weeks.
- …but also stay flexible. Although routine is important, not every line of code needs to be written by a pair. Regular code reviews are a necessary part of our process that help on a more retroactive level.
- You can even use pairing for more than just programming! You can apply pairing to sprint planning, documentation, proposal writing, architecture, and so on. We even wrote this blog post as a pair while sitting in different cities with help from Google Docs, which allows two people to type at once. (We ate donuts instead of pears as we wrote, but we agreed to start pair pear grocery shopping next time so we make healthier choices.)
Following is a picture of us that the local BitLoft paparazzi captured. We sometimes take our laptops and sequester ourselves in a conference room to focus.
Drop us a line at firstname.lastname@example.org and tell us how you have used or are hoping to implement pair programming at your company!
Ethan Ransdell and Nate Read are developers at BitLoft. A day doesn’t go by without their colleagues finding them huddled together around a single computer. You can contact Ethan at email@example.com, and both Ethan and Nate will pair read your message!