Article summary
As a long-time developer at Atomic Object, I’ve had many opportunities to work with developers who were new to pair programming. Whether pairing with senior developers who’ve been working solo for their entire careers, or with a new hire straight out of college, I’ve run into almost the exact same situation every time.
Here’s a sample scenario:
Me: Hmmmm. That’s strange, I expected the test to pass this time…
Pair: Um, could it be that we’re passing the wrong thing to that function?
Me: Ah, yes. Look at that. I completely botched that. Good catch.
Pair: Yeah, I noticed it a bit ago, but I figured you knew what you were doing, so I didn’t mention it.
My pair, who’s new to the project, perhaps new to the language, and possibly even new to being a professional programmer, spotted my mistake right away! This is what makes pair programming so great. Much of the time, you don’t need to wait for the compiler or a unit test to catch a mistake—you’re getting a real-time code review as you type.
But only if your pair says something!
Speak Up
So my tip for any developer just getting started with pair programming is: If you think your pair has made a mistake, there’s a very good chance you’re right–so speak up!
Politely
Since you’re likely just getting to know your pair, you’ll want to be polite. For example:
“Maybe I don’t quite understand yet, but I’m wondering about why we’re passing that value to the function.”
If you just caught a mistake—fantastic! Your pair will happily fix the problem, and you will have added value to the project.
If it wasn’t a mistake, and you were wrong—it’s better that you spoke up. Your pair now knows that more explanation is needed, and it becomes a learning opportunity for you.
More often than not, when my pair sees something that doesn’t seem right and attributes it to me “knowing what I’m doing,” he or she is wrong. You should speak up. Regardless of who’s “right” or “wrong,” improved communication is always a win for the pair.
At the right moment
You should give pairs a moment to finish their thought and complete what they were typing before you interrupt. It’s possible they’ll catch their own mistake (especially typos). Or maybe they process things in a different order than you and just haven’t gotten to it yet (e.g., putting the semicolon on the end of the line).
Give your pair a moment before you say anything—but don’t just sit on it because you think he or she knows something that you don’t know.
Communication Success in Pairs
After thinking about this idea, I’m going to let my future pairs know how I prefer to communicate, based on what I’ve seen work over the years.
Seasoned or new developers—what has helped improve your communication flow with your pair?
This sounds a lot like the Crew Management issue in airline piloting. This is specific instruction and training to make sure junior pilots speak up when they see anything wrong or have questions or concerns with what the pilot in charge is doing. It is necessary to overcome the natural (or perhaps cultural) behavior of assuming the more senior pilot “must know what they are doing”. Like software development, pairing in the cockpit helps catch errors or omissions early, but only if both parties have the confidence to speak freely.