It is widely known that pair programming helps produce code that is cleaner, more maintainable, and has fewer errors. Conscientious software development companies go to great lengths to outfit their employees with both the equipment and the environment necessary for pairing.

So what can you, as a well-meaning professional developer, do to contribute more to your team? In part one of this series, I outline two great suggestions that will help guide you towards your pair programming potential.

Be flexible when it comes to tools

With both the tools you use and your schedule, you are going to need to give a little to get a lot. Not every developer will be comfortable - or even familiar - with your particular configuration of tools. We all have our preferred text editors, package managers, command line shortcuts, database visualization program, etc.

It does very little good to try to standardize a group of strong-willed, opinionated, smart software developers on some arbitrary combination of company-approved tools. Instead, it is best if each pair can work out - as compassionate adults - the particular combination which will produce the best results and sense of satisfaction for the people involved in the project.

This is especially true when you have remote developers pairing, either with one another, or with developers in your home office (assuming you have one). There are few quicker ways to irritate a programmer than to force them to learn a whole new set of tools they think they don’t need, in the interest of standardization.

In my experience, what works best is to let the driving partner dictate the tool choice. When I am taking the back seat as a pair, I am perfectly content to let the other person use whatever tool they like since I am not likely to do much actual programming in this configuration anyway. Instead, I will be shoulder-surfing for typos or logic errors, searching the web for solutions to problems that crop up, communicating with the broader team, and performing other tasks on my own computer.

Sometimes while pair programming, I will witness a tool in use by a skilled pair partner which in turn encourages me to try it out on my own time. I enjoy that type of organic learning experience more as opposed to trying to learn that same tool under the watchful (and potentially critical) eye of a more experienced user.

Work together when it makes the most sense

Schedules are complicated. It’s challenging enough to arrange a 30-minute meeting with someone, let alone trying to find a three-hour window when you’re both available! Developers have a wide array of demands on their time. Some are work-related and some not. There are a variety of needs to be considered in scheduling your pairing time.

In any given day, I or my pair partner may need a break for:

• a meeting
• nature’s call
• greeting kids returning home from school
• researching a problem
• sanity
• exercise
• a doctor’s appointment
• a crying baby
• emergency donut-tasting in the breakroom

No judgment! If you want to enjoy your pair programming experience, you want the developer you’re pairing with to be happy as well. If they’re happy, they are more focused, easier to work with, more creative, and more productive.

The key, I’ve found, is to formulate a game plan at the beginning of each day. Our team always starts with a morning standup meeting. After that, if I’m pairing, I convene with my pair partner and we both share our known interruptions for the day. This is especially critical when one or both of you is remote, and when there is a different time zone involved.

Mine usually goes something like, “OK, I have a long lunch at 12:30 your time, and a kid appointment has me leaving by 4 your time. I’ll be back on in the evening.”

My pair might respond with, “I have a meeting at 10:30, and we’re going to a long lunch to celebrate Joe’s birthday at 12.”

After sharing any possible interruptions, we then know how to hand off the project when we take our breaks. We communicate the state of the project at the turnover points and work diligently during those precious hours that we are both available.

It might sound crazy, but bottom line: it works.

In the next installment of the How to Become a Better Pair Programmer series, I’ll share with you how to be realistic with your expectations and how to navigate the tricky waters of assumption. In the meantime, try using some of the tips mentioned above and see how it goes.

To skip around to other parts of the series, use the links below:

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