Jason Garber - Practical Pair Programming

In this book youll find practical advice on pair programming for the beginning programmer, experienced software engineer, team lead, or engineering manager. Everything Ive 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 developme nt 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 th e 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 companys projects went off the rails (and we had to write off hundreds of thousands of dollars), its almost universally attributable to solo pr ogramming.

Pairing doesnt mean doubling the cost to get the same output. I like to say its the same cost for a product thats twice as good! So why do people say pair programming isnt efficient? Developer Sean Killeen posits that theyre not thinking of the long-term velocity and overall team effe ctiveness:

I think its because lots of people think short-term when they say efficient. I program faster alone, and more effectively when not alone because Im optimizing for the system and team rather than myself. ( http://bkaprt.com/p pp/00-01/ )

Pair programming also isnt backseat typing. An unfair balance of control at the terminal will be more annoying than a backseat driver in your car. In Chapter 2 , well go over ways to ensure you and your pair get equal time driving and keep your commentary con structive.

Finally, pairing isnt about group code review. You may think its more efficient to have people work individually, then revise with a buddy, but this isnt 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.

Pair programming is two developers working on the same code using shared controls. In Chapter 1 , well cover the many benefits pair programming offers, including higher-quality code, improved team communication and cohesion, and overall work sati sfaction.

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 profes sionally.

Id 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 y our team.

Chapter 1 discusses why you should pair program: the benefits to yourself, your team, and your wor k product.

Chapter 2 lays down some fundamentals of getting started with pair programminghow 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 dont end up pai ring 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 thats not set up with pairin g 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 P ractice .