Last week I shared with you the importance of flexibility while pair programming. Regardless if you’re dealing with development tools or people, it is important to remain open and patient with your partner. Part two is going to focus more on why you should check your ego, not jump to conclusions, or make wrong assumptions.

Be Realistic - Pairing takes time

Pair programming usually produces better code, but it doesn’t usually produce that code faster. Producing software collaboratively and thoughtfully requires discussion, research, and trial and error - all of which will add time. Make sure you take this into account when giving production estimates to a client.

I find the multiplier on pair programming to be roughly 1.5. So, if a feature would normally take you 12 hours to code yourself, it will take roughly 18 hours (12 * 1.5) to produce with a pair. That extra time will be more than made up for by the improved quality, maintainability, and customer support savings.

Check your ego at the door

Even in a situation where there is a clearly senior pair partner, it doesn’t behoove anyone to act like a jerk. Regardless of your relative seniority, remember that you are working with a person that has feelings, thoughts, and opinions. We all have flaws and fears, so it’s important to be courteous. Once you’ve worked with a person for some time, you’ll get a sense of whether or not a joke would be well received and welcome. Until then, err on the side of caution and be polite.

Checking ego goes beyond being nice, however. No matter how long you’ve been a programmer, there is always more to learn - and to teach. At its most elemental, that’s what pairing is - a mutual sharing of information. If you are closed off to either giving or receiving knowledge, you are going to make for a terrible pair partner.

Assume the best

When forced to make guesses - either about your pair’s abilities or her motivations - assume the best. Misunderstandings happen between people all the time, and they are only exacerbated by an assumption that someone has ill intent or lack of skills.

Take this scenario as an example: you and your pair partner are tasked with writing a new reporting feature for your application. You’ve gotten the majority of the functionality in place, but you notice there are several places you’re duplicating code. When you suggest refactoring to extract the duplication to a reusable function, your pair responds, “No, we can’t do that” and plows ahead with the remnants of the feature.

From that sort of reaction, it can be tempting to assume your pair doesn’t value your suggestions, or maybe they reacted that way because they don’t have the chops to pull off this relatively simple refactor. Either of those two scenarios may very well be the case, but that’s not where your reasoning should start.

Instead, give her the benefit of the doubt. Maybe there’s a deadline that’s come up you haven’t heard about, and refactoring needs to wait until later.

Or, maybe she’s already tried a refactoring like the one you suggested and she knows performance will take a serious hit.

Another thought? Maybe she just misunderstood what you were suggesting altogether.

Don’t drop your suggestion out of hand - it’s your duty to speak up and improve the codebase, after all! Instead, gently tease out her reasoning. “I’m curious why you think my suggestion wouldn’t work. Could you explain a little better for me? I want to make sure we can stay on the same page.” Once you understand the reason for her dismissal of your suggestion, then you can have a fruitful discussion about whether to take on the refactor.

Working with another person so closely can be difficult at times. If pair programming was easy, then everyone would be doing it. Here at Collective Idea however, we find true value in this development model. Hopefully, the tips shared here are simply a good reminder that although pair programming isn’t the easiest, it can truly be rewarding for all parties involved when you extend a little patience and empathy towards your pair partner. In the third part of the How to Become a Better Pair Programmer series, we’ll look at knowing your limits.

If you’re interested, here are links to all of the blog posts in this series.

Part One - Tips and advice for creating a cohesive collaborative development environment

Part Two - Getting realistic and assuming the best

Part Three - Knowing your limits

Part Four - Knowing what role to play and when