At Tighten, one of the ways we ensure high-quality work is to always try to avoid putting code into production without at least one other set of eyes reviewing it. While on single-developer projects this often comes in the form of a code review from another member of the team, whenever possible we like to assign two developers to a project so that pair programming is an option.
Pair programming is an Extreme Programming practice in which two developers work together at the same time (traditionally, at one computer, passing a single mouse and keyboard back and forth).
When we tell someone that we have a strong pair programming culture at Tighten, we often get one of two reactions:
The Disbelievers: Pair programming is awful because it wastes time / I hate being around other people / you're charging half as much for twice the work!
The Purists: What? You can't effectively program with your teammates when you're not sitting in front of the same computer.
I'll admit that I spent several years in the first camp: sitting at a computer next to someone all day sounded absolutely terrible. What would happen when I didn't know something: would my pair think I'm stupid if I have to make a pit stop at Stack Overflow? What if I'm having an off-day where I don't really want to talk to anyone? What if I want to eat a gyros sandwich (with extra onions, of course) for lunch?
Once I spent some time actually pairing, however, I found my opinion changing. True, there are plenty of tasks we don't pair on at Tighten: two developers aren't needed for things like writing basic markup, easy refactoring, or anything especially tedious or mindless. But for heavy feature development, two developers can definitely be better than one.
There are a few major benefits to spending at least some of your time pair programming:
Like we mentioned in our post about the tools we use at Tighten, we are big fans of Screenhero for pair programming. One developer can share his or her screen with another, and both can use their mouses and keyboards to interact with it. While it isn't perfect software — we've hit more than one technical issue in our years of using it — it's usually fast and reliable. Screenhero has closed new signups while they're working to integrate with Slack, but you can get an invite from an existing user, and (for now, at least) it's free.
(And since you're not physically sitting next to your pair, you don't have to worry about what you ate for lunch that day.)
Even though Tighten developers are scattered all across America, this actually presents less of a challenge for pair programming than one might assume. We have a fair amount of flexibility in our working hours, but generally, the entire team is present between about 11-3PM EST, and this is when much of the pairing happens. Even if one developer on the east coast works from 7-3 EST and pairs with another on the west coast who works 11-8 EST, they'll still have half of the day together.
Often, one developer will start a feature in the morning before the second gets in; they'll spend a few hours mid-day pairing together; and the second developer will wrap it up and QA it after the first developer leaves for the day. If the second developer opens a PR in the evening, the first developer can do a quick review and merge it after they start their day the next morning.
This sort of cycle also reduces developer fatigue from pairing. Even the most outgoing extrovert might find working with another person for 8 hours a day exhausting; it can be a lot harder to pace yourself when you don't feel like you can take the occasional Twitter break to reset your brain. We've found that limiting our pairing to four or five hours a day, with the occasional coffee break to step away from the computer, seems to be the sweet spot.
Pair programming isn't a panacea that will magically make your code perfect and bug-free, but if approached in the right spirit, it can definitely make your code and your developers better.
Have any questions about how or why we use pair programming at Tighten? Hit us up on Twitter!