Pair programming has become popular as companies embrace the Agile approach, and everyone’s full of anecdotes and opinions about whether or not it works. But regardless of the efficacy of the practice in general, there are a few things we can all do to become better at pairing. Read more on Four Keys to Effective Pair Programming…
Some people are naturally inclined to pair. Not me. My brain is all over the place when I code, so it’s difficult to focus energy on solving the problem at hand while explaining my reasoning and approaches to my pair.
This thing is, pair programming is a highly-regarded and widely-practiced convention here at Atomic. When I started here, I had never paired before. And I was quite surprised to see both how effective it was for others, and how difficult it was for me.
Read more on How I Learned to Love (or at Least Like) Pair Programming…
One big thing that Extreme Programming got right is pair programming. Rather than waiting until work is complete to review code with another developer, the authors of XP figured that if having two pairs of eyes on code was important, why not do it continuously? Read more on The Many Uses of Pairing: Replacing Post-Work Review with Collaboration…
As a long-time developer at Atomic Object, I’ve had many opportunities to work with developers who were new to pair programming. Whether pairing with senior developers who’ve been working solo for their entire careers, or with a new hire straight out of college, I’ve run into almost the exact same situation every time.
Explaining the benefits of pair programming to someone new to the concept can be difficult, particularly when that person has the initial, understandable, reaction that they’ll be paying two developers to do the work of one—why would they want to do that?
But recently, on one of my favorite podcasts (The Skeptics’ Guide to the Universe), I heard an interesting dairy-based metaphor for how experts can work together to solve problems that one alone cannot. It provided a unique way of looking at the issue—one I think can quickly and effectively show how pair programming can be leveraged as a tool to help build the highest-quality software.
I recently had the opportunity to pair with Scott Vokes on a side project. He had an idea for a simple C program and let me drive while we talked through the design. In a few short hours, I learned a lot more than I expected. I’ll add the list below.
I started pair programming in 2000 on my first real software job, while I was still working on a computer science undergraduate degree. I’ve been mostly pairing in daily practice since then.
First Impressions Matter
My earliest perspectives on pairing are useful because I’ve seen bad results when people are denied the chance of finding out its benefits for themselves. Pair programming wasn’t prescribed or preached to me, it was encouraged. Read more on Reflections on 10+ Years of Pairing – What Works, What Breaks, and What’s Next…
While I’m a software developer by trade, I’m also the mother of two school-aged kids, so one of my pastimes is volunteering in various capacities at our local public elementary school. At some point early this school year, in a moment of temporary insanity, I found myself nodding my head “Yes” when a wiser full-time-working parent would be saying “No”, and next thing you know, I had agreed to lead an after-school Computer Club for 4th and 5th graders.
Something I’ve observed that you may have also: by the time a kid is 9 or 10 years old, they are already incredibly capable of wasting copious amounts of time on a computer. This age group (ok, all age groups?) would happily spend all their time playing computer games — Minecraft being the game of choice these days.
My goal with Computer Club was to get the kids away from just playing games and into creating something with their computers — maybe even creating their own games. After a quick survey of developers with kids and the Internet, I settled on teaching basic programming concepts with a language/platform called Scratch. Read more on 10 Tips for Running an Elementary School Computer Club…
For the last several months I’ve been pair programming every day, working with another developer on a Windows application. Both of us usually use Macs, so we’ve adopted a company Windows laptop to do the work, and as we’ve experimented with our pairing tools, we’ve learned a bit about how tools affect getting the job done.
Alternating Mac & Windows, Dvorak & Qwerty
When we started on the project, my pairing partner and I sat with our Macs in front of us and the Windows laptop in between, pushing the PC back and forth depending on who was driving. The keyboard and trackpad were unfamiliar, and despite weeks of using them, we still only tolerated them, frequently sighing at clicks we didn’t mean to make and keys we didn’t mean to hit.
Since starting at Atomic, I’ve had to use remote pairing on several occasions to work with developers who were not co-located with me. I wanted to give an overview of some of the different tools I’ve used for remote pairing and what I like/don’t like about them.