In this book you’ll find practical advice on pair programming for the beginning programmer, experienced software engineer, team lead, or engineering manager. Everything I’ve written comes from my own pairing experience, having worked as a developer on teams that were resistant to Agile and Extreme Programming (XP) practices, up through becoming a manager of a successful software development firm.
Bigger and more mission-critical software projects require larger, more diverse teams. Counter-intuitively, the greater the number of contributors on any one project, the harder it is to coordinate and finish software on deadline. Pair programming perhaps strikes the ideal balance between solo work and software development processes that need a giant flowchart to be understood: not too rogue and not too rigid; nimble but without the risk of having just one pilot in the cockpit.
Can successful software be made by one super-smart solo programmer? Sure! But in my experience, pairing is safer and more enjoyable than working alone. In fact, as I think back to my big mistakes as a programmer or the times my company’s projects went off the rails (and we had to write off hundreds of thousands of dollars), it’s almost universally attributable to solo programming.
Pairing doesn’t mean doubling the cost to get the same output. I like to say it’s the same cost for a product that’s twice as good! So why do people say pair programming isn’t efficient? Developer Sean Killeen posits that they’re not thinking of the long-term velocity and overall team effectiveness:
I think it’s because lots of people think short-term when they say “efficient.” I program faster alone, and more effectively when not alone because I’m optimizing for the system and team rather than myself. (http://bkaprt.com/ppp/00-01/)
Pair programming also isn’t “backseat typing.” An unfair balance of control at the terminal will be more annoying than a backseat driver in your car. In Chapter 2, we’ll go over ways to ensure you and your pair get equal time driving and keep your commentary constructive.
Finally, pairing isn’t about group code review. You may think it’s more efficient to have people work individually, then revise with a buddy, but this isn’t a creative writing class. Two people need to be involved in the creative process together, from inception through development, to capture all the benefits of pairing.
What pair programming is
Pair programming is two developers working on the same code using shared controls. In Chapter 1, we’ll cover the many benefits pair programming offers, including higher-quality code, improved team communication and cohesion, and overall work satisfaction.
When two people are at the controls writing code, twice the empathy is employed for your users, teammates, and future selves. With two different sets of experience, you can train one another. If one of you needs to step away, the other can keep things moving briefly. And when something goes wrong, two brains are better able to solve the problem calmly and professionally.
How this book is structured
I’d recommend you skim the whole book to get the lay of the land. Then feel free to jump around and dig into whichever parts are most salient for you and your team.
Chapter 1 discusses why you should pair program: the benefits to yourself, your team, and your work product.
Chapter 2 lays down some fundamentals of getting started with pair programming—how you make the radical change from solitary, silent work to collaborating as an engaged, dynamic, and conversational duo, and avoiding pitfalls.
Chapter 3 helps you be the best pairing partner you can be and bring out the best in others so pairing is a sustainable source of productivity and joy. The approaches I present will help you become a better collaborator, even if you don’t end up pairing much.
Chapter 4 deals with the nuts and bolts of getting set up for pairing to mitigate fatigue as best you can. A common complaint is that pair programming is exhausting, due in no small part to a physical or virtual workspace that’s not set up with pairing in mind.
Chapter 5 looks at pairing in the context of a team and making it a part of your team culture without triggering a backlash. We then go on to explore ways that pairing on the team can get stagnant and how pairing feeds into a larger concept of the Community of Practice.
By the end of the book, I hope you’ll be sold on the value of pair programming, and even more so, internalize the values that make pair programming so enjoyable. I want you to know what it feels like to work with colleagues who are eager to exchange knowledge, care more about quality work than their egos, are reflective and insightful, and want to see everyone’s contributions valued. If these colleagues don’t sound familiar, this book will help you be an example to your team, help move them in the right direction, or perhaps find a different team of well-adjusted humans that deserve your presence.