I work on a team where we practice ‘pairing’ and pair programming every day. Before joining this team I had only a passing experience with pair programming. And now, after many months of pairing, I have a much better understanding of why we pair.
Pair Programming Explained
Pair programming is a technique in which 2 programmers work as a pair at one workstation. One, the driver writes code and focuses on the tactical aspects of syntax and task completion. Two, the observer considers the strategic direction of the code they’re writing together. In our case, each developer has their own monitor, keyboard and mouse but is connected to one IDE. The two programmers switch roles often.
Two Heads Are Better Than One
Pair programming is often paired with the concept of build, measure, learn. Both concepts are complementary and lead to some of the following benefits …
- Quality: Higher quality code which leads to happier customers and fewer escalations. The shortened cycle of build, measure, learn provides immediate validation for developers as they implement production quality code.
- Expertise over Specialty: Pairing promotes expertise not specialty – it matters a little less if someone gets hit by a bus, although we do still care.
- Empathy: Pair programming builds empathy through shared goals, shared problems, shared results, focus, removal of wasteful activities. Through pairing we get to know each other and that makes a difference.
- On-ramp: New hires come up to speed quickly by pairing with an experienced programmer. They acquire a broad understanding of the system and over time fill in any knowledge gaps.
- Rotation: Pairing rotation expands the knowledge and perspective of every developer on the team and up-levels everyone’s knowledge consistently and quickly.
- Shared Responsibility: A pair is jointly responsible for the success or failure of the work they are engaged in.
- Adapting to Change: Teams who practice pair programming are often highly adaptive. Change becomes part of the team’s DNA, the team structure changes every day.
- Engagement: Programmers are more likely to be engaged if you’re having a bad day, there’s no hiding when pairing.
People think there’s no simple way to get started, in our case there was … we just started. We started by Pairing – we learned along the way and we continue to learn. We employ the concept of build, measure, learn to inform how we adapt to our successes and failures as a team. Everyone’s opinion on the team is important and becomes a factor in any decision we make.
Your environment supports your ability to pair program. Two programmers sit together, lean teams are colocated and programmers sit with other key members of the team, designer, product manager, anchor. It would seriously constrain a team’s ability to succeed if they did not sit in an open collaborative environment. I strongly recommend getting rid of cubes and offices. Pairing is the first step to change (after you tear down the cubes).
Pairing creates empathy and I love working with everyone on my team. I understand them, even though we’re professional and kind to each other, it often feels like I’m sitting down with a friend to work on a problem. We learn by doing and we care about each other. None of us would ever go back to working in cubes or offices. None of us would ever want to solo again. We’d miss the benefits our pair brings to our code quality and work satisfaction.
If you’d like to learn more about how we pair, or how you can get started, come visit us at the #EMCDojo. We would love to give you a tour and perhaps, if you have the time, you could even pair with us. After all, learning by doing is at the heart of everything we do.
Email Brian RocheTags: cloud foundry, cloudfoundry, dojo, emc, emc dojo, EMCdojo, extreme programming, pair, pair programming, pairing, XP, xtreme programming