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.

The Why

There are a few major benefits to spending at least some of your time pair programming:

• Code Quality: This is unquestionably the single biggest reason to pair with another developer. Having another set of eyes on your code as you write it will almost always lead to better code; you will be receiving not only real-time code review for possible bugs or inefficiencies, but will also benefit from another brain considering other angles to approach a problem. If you support this code with a solid test suite, it will absolutely be more bulletproof than code you write alone.
• Accountability: You know those days when it feels like you're spinning your wheels and spending a bit more time on Slack or Twitter than you probably should? When you're pair programming, you don't really get to have those days. Spending your day working with another developer forces you to be more disciplined about your work habits, which leads directly to our next benefit...
• Speed: This one is perhaps counter-intuitive; it's easy to assume that two developers will work at half the speed, but in my experience, this is rarely true. Aside from the inherent speed boost you get from writing cleaner code in the first place (with far less time spent squashing bugs!), you'll generally spend less time searching for solutions to problems when you're working with another developer. That other person may remember that tricky array syntax you forgot or how to write a SQL left join without having to look it up, or they may notice that you're starting to code yourself down a rabbit hole by pursuing an inviable solution. As a worst case scenario, even if you need to spend some time Googling for an answer, you'll have another person filtering through results at the same time.
• Knowledge Transfer: While there is definitely value in a partnership between a senior and a junior member of a development team, many of the best pairing experiences happen with someone who has a relatively similar skill level. The width and breadth of our field is so large that there are always things to learn, and the sweet spot seems to be when developers share a similar knowledge base but each have fringe nuggets of wisdom or insight. You and your pair might not need to spend time explaining the basics of ORM relationships to each other, but if your pair knows when to use a polymorphic many-to-many and you're a pro at optimizing query speed, you're both going to walk away from a project as better developers.
• Code Ownership: Like I already mentioned, at Tighten, we try to make sure that any code that is deployed to production has at least one other set of eyes on it. While this often comes in the form of code review on Github pull requests, especially on single-developer projects, there's only so deep that code analysis can go when you're not familiar with the project. On the other hand, when your team utilizes pair programming, it's easy to onboard new developers to a codebase and make sure everyone has a working knowledge of the user stories and the nuances that informed design decisions.
• Team Bonding: When you're a member of a 100% distributed team, it can be difficult to form a meaningful relationship with co-workers that you only see in person once or twice a year. Pairing forces you to spend time with people that you otherwise may not interact with aside from casual Slack interactions, and sharing the many frustrations and successes of working on a project together are a great way to form lasting friendships.

The How

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.

Conclusion

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!