Pair Programming is a practice I learned from Steve Cohen when building our Rails app at Dojo. We practiced it along with TDD to build out new features, and we worked with two keyboards/mice on one computer. We played a game where one of us would write a test, run it, watch it break, and the other would fix the breaking test with production code.

Since then, I’ve been lucky enough to pair with many other bright minds, some more experienced and some less. With more junior developers, it’s a great way to pass on techniques and strategies that can easily be overlooked in a code review. I find it to be an incredibly fun and fulfilling experience.

Benefits

  • You automatically get diversity of ideas just by the nature of the practice.
  • You get real-time feedback from your team members rather than having to wait until the code review.
  • It builds confidence in your skills and tactics by vetting them immediately.
  • It builds trust between teammates.
  • It gets programmers in the practice of sharing ideas with each other–not just with code but also communicating verbally.
  • It lets the pair celebrate the wins together, and if you’re TDD’ing, you’ll also get little wins along the way of fixing each test.
  • Practicing pairing as part of an interview or onboarding process makes transfer of knowledge easy and fast.
  • You’ll likely find out new workflows and hotkeys from each other that you hadn’t known about before.

Slow down/Speed up

  • When you pair the first few times, you’ll probably be slow, and you’ll probably feel a little nervous with each other. That’s perfectly OK and a bit to be expected. You’ll start getting used to each other, and you’ll start speeding up and getting into a good rhythm with each other sooner in your session.
  • When I paired with Steve, I could tell he was often zooming fast forward and head to the solution. Meanwhile, I was still thinking through the consequences of decisions along the way. Most of the time, he was on the mark, but once in a while, there would be something he’d overlook. Even more seasoned developers will overlook things, and the less seasoned of the pair can still add value by checking assumptions and asking good questions.

Some things to note

  • It’s exhausting, so be sure to take breaks often: it’s useful to set a timer for an hour so you can both take a breather.
  • There’s no chance of either of you checking Facebook or Hacker News, so you’re staying focused and productive the entire time; well, you could do it, but you’d be kind of a dick to do so.
  • When pairing with 2 skilled senior devs who are familiar with each other’s styles, the process becomes magical, and coding becomes an incredibly fun team sport. I experienced this several times with Mike Watts while we paired on code for Little Countdown.

Social Coding

Since I really enjoy coding, I schedule pairing with my other coding friends in our free time and screen share. We’ll each pop open a beer at home (or wine, or whiskey), and we’ll set a timer, and start. It’s a great way to socialize while doing something we both love to do. It’s fun to play pool or ping-pong, but it’s also fun to collaborate with other geeks and do what we love to do best: code.

Notes: