When you start something new, there’s always kind of a make or break period. A good first impression can win a convert for life. Conversely, a bad first impression can win a critic for life. This is true for just about any pursuit. But it’s especially true for pair programming.
Why? Well, in the development community, pair programming has plenty of ardent supporters, but also plenty of passionate detractors. If, as a shop, you decide that the pros outweigh the cons, it’s unlikely that everyone will share this opinion. Right from the get-go, you’ll have ambivalent or reluctant adopters.
So for that reason, I want to offer some pair programming tips specifically for beginners. Here’s how you can avoid stumbles out of the gate that might knock you off track permanently.
Get TestRail FREE for 30 days!
1. Hygiene Matters a Lot When Pair Programming
Let’s get the awkward one out of the way first. Hygiene matters, and that can always make for some wince-inducing conversations. You need to have these, though.
When you start pair programming, you’re going to have folks sitting in closer proximity to one another than they’re used to. And they’ll do it for extended periods of time. So breath mints, showers, not reeking of cigarettes, deodorant — this stuff matters.
Lay out some ground rules.
2. Ask Questions Rather than Leading with Opinions
Many software developers have many opinions. These are often strong opinions. And the holder might often express them bluntly.
In a pair programming context, this can lead to acrimony in a hurry, threatening the enterprise in general. “That’s a stupid thing to name a variable” or simply “that’s wrong” don’t start discussions — they start arguments. You want to avoid this.
One easy way to counteract this impulse is to favor questions instead of opinions. Don’t tell someone the variable has a bad name. Instead, ask them why they named the variable what they did. When you ask for explanation first, you start a discussion. Now, that discussion may still lead to disagreements or debate, but it will start off on a constructive foot.
3. Resist the Impulse to Interrupt
The next tip is similar in the sense that it seeks to preempt interpersonal issues. Everyone working in pairs needs to resist the impulse to interrupt the other person, both when they’re talking and when they’re writing a line of code.
This is a hard one, particularly for people who are enthusiastic and gregarious. Some folks get animated and want to finish their conversation partners’ sentences. Or maybe they see where the pair partner is going with a line of thought and start telling them what to name a variable or put a guard clause.
And some people react to this in kind, counter-interrupting and generally enjoying the exchange. Interrupters can be compatible with one another. But they can also completely shut down more reserved pair partners. These folks will go silent, take a backseat and nurse resentment. Establishing “don’t interrupt” guidelines help to make sure that everyone is comfortable and heard, and not just the loudest, most excited people.
4. Don’t Sprinkle in Solo Work
Now that everyone smells good isn’t fighting and interrupting one another, we can move on to some logistical concerns. First up among these, don’t sprinkle in solo work.
Let me set the scene. A pair of developers is working gamely on some feature when one gets an important personal call that she has to take. She gets up to take the call. While she’s gone, her partner shrugs and says, “well, I guess I’ll just keep going.”
It’s a little counterintuitive, but resist the impulse to do this. When you do that, it’s jarring to the temporarily detained pair partner, for sure. She’ll come back and feel less involved in the feature. But, beyond that, it can easily turn into a sort of “race” where you can get your way by outlasting the other person.
If you’re going to pair, then pair. When someone has to take a break, the other person can work on other things, like email or a different project.
5. Take Breaks
Speaking of taking breaks, take breaks. If you’re used to working alone, you might have a tendency to think you’re a lot more productive in uninterrupted fashion than you actually are. “Work for 3 hours straight? No problem! I do that all the time.”
Except, you probably don’t. You probably stop every time you get an email to see who it’s from. You probably get up for more cups of coffee than you realize. And, let’s be honest. You probably go on Facebook more than you want to admit.
When you’re pairing, you don’t do those things. So you wind up staring at the prospect of actual hours of non-stop work, which will exhaust you, particularly if you’re not used to lots of collaboration. Get up and take a lot of breaks. The Pomodoro technique can fit well here.
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
6. Don’t Let Passivity Slide
Let’s say that you’re paired up with someone. You’re coding along, getting into a state of flow and feeling pretty productive. And then it occurs to you. It’s as if you’re working alone.
When this happens, don’t just shrug and keep going. Stop and engage your pair partner. Ask him to take over at the keyboard and mouse, or, at the very least, ask him for his opinion. Ask him if he understands what you’re doing or if there’s anything he’d do differently.
Pair programming should be an ongoing conversation, reminiscent of a mashup of coding and code review. It shouldn’t be silent and nobody should be passive. If you’re doing that, then you’ve just got one person working and another person spacing out while watching.
7. Learn the Lingo and Techniques
I’ll close with perhaps the most important tip I can offer. You should learn the lingo and techniques commonly used by folks that pair a lot. People have given names to popular pairing approaches, such as driver-navigator and ping-pong pairing.
Things get names when they have well-worn paths to value. So by learning what others have done and had luck with, you’ll increase your chances for success. You can do a lot worse than modeling your approach after others who have used a technique effectively.
This is a guest post by Erik Dietrich, founder of DaedTech LLC, programmer, architect, IT management consultant, author, and technologist.
Test Automation – Anywhere, Anytime
