Introducing Pair Programming
Ever been engineering and gotten stuck on a seemingly trivial problem?
It looks easy, but it takes minutes or hours to find out if you’re making progress.
It might look like there’s a path forward with a config or variable change, but it doesn’t pan out.
Remove the offending code?
Something else breaks.
Replace the dependency?
Different errors.
Maybe trying a code change again might do something different this time?
Nope.
Now it’s a few hours in, the curiosity starts to fade and the frustration starts to kick in.
After going in circles for a few more hours, head-desk stress relief starts to seem like a great option.
A few days later, mentioning this intractable problem to a coworker, they say:
“Oh yeah, all you have to do is [fix the foo with bar]”
You put the bar on the foo and suddenly it works.
Problem solved.
All it took was a few days of frustration and a helpful comment from a coworker.
Were those days of down-time and frustration even necessary?
What if helpful comments could come sooner?
Introducing Pair Programming
Pair programming is a way for engineers to collaborate that empirically improves the quality of the product made. Per a well-cited paper [Cockburn, Williams],
“[F]or a development-time cost of about 15%, pair programming improves design quality, reduces defects, reduces staffing risk, enhances technical skills, improves team communications and is considered more enjoyable at statistically significant levels.”
While practicing pair programming for a couple of years, my favorite experiences have included:
- Learning faster
- Getting stuck less often
- When stuck, getting unstuck faster
- Developing trust with coworkers
- Being capable of socializing after the end of a work day
While pairing does have clear benefits, there is a catch.
Pair programming is a “team sport,” so it requires the willing (if not enthusiastic) collaboration of 2 or more people.
Since many engineers are used to engineering on their own, this poses a problem.
How do you start pairing if your whole team likes to work alone?
Ask to pair
… and get shot down.
Because that’s a really big ask for someone who’s never tried pairing before.
You asked “would you like to pair?”
They may have heard “would you like to change your whole workflow to something that you know little about, challenges your beliefs, exposes your flaws, and is really difficult?”
Given that, it’s entirely reasonable for them to respond to your request with:
“Nope.”
Each person has the right to say “no” to a request and we respect that.
After all, pairing is about collaboration and it’s really hard to collaborate with someone who doesn’t want to collaborate.
Let’s dive into some of the unconscious reasoning that led to the initial “no.”
With no additional information, what might an engineer think they know about pairing?
It’s unfamiliar
“Pairing, what’s that?”
This may have been the first time they’ve heard of pairing.
“If it’s so rare that even I don’t know anyone who has paired, how good could it possibly be?”
Conclusion: Working alone is the norm.
It challenges my beliefs
“I’ve always been the sort of person who needs to work alone to get stuff done. Others just haven’t been able to keep up.”
A core part of a software engineer’s identity might be tied up in working on their own.
“I’ve put so much time into refining my process of working alone. If I switch to working with others, then all that effort will have been wasted.”
Conclusion: Easier to continue doing what I’m used to.
I could look bad
“You mean I have to show my code to someone before it’s ready? My coworkers will think I’m incompetent!”
Starting something new inevitably means making mistakes. When mistakes aren’t seen as growth opportunities, then doing new things can induce anxiety and apprehension.
“If I try pairing and I do it wrong, then everyone will think I’m bad at programming”
Conclusion: Better to stay isolated and code on my own.
Oof.
Pairing doesn’t sound pleasant at all given those beliefs.
It’s little wonder that someone might be hesitant to give it a shot.
What now?
It might be easy to get discouraged here.
After all, none of the reasons for declining pairing have anything to do with the objective reality.
The comparison of advantages and disadvantages of pairing versus working alone are completely absent.
Instead, what would it look like to get past the initial hesitation and give pairing an honest appraisal by trying it out?
Reinforce empowering beliefs
There’s a series of beliefs that we can reinforce in others to help them try out something new.
It’s safe
When someone trusts that you have their best interests in mind, they’re more open to trying out your idea.
Further, when it’s psychologically safe to make mistakes, people are more likely to adopt a new behavior.
They’re in control
When people make decisions in support of an outcome, they become more invested in it.
Higher investment leads to more follow through.
It’s a win for them
When people hear a call to action that is in clear alignment with their beliefs, commitments, priorities, and incentives, it intuitively feels like a win.
Intuition informs in-the-moment decisions, especially before the brain dedicates time and energy to deliberately process facts and data. [1]
Sounds useful, but what does starting to pair look like in practice?
It looks like taking a moment to imagine yourself in the shoes of your coworker:
- What pressures are they under?
- What projects, tickets, or stories are they already working on?
- How can you help make their life easier?
Then from that place of empathy, making a request.
This might be via Slack, in person (my favorite), or even via email (gasp).
Regardless of the request’s medium, it’s important to authentically convey empowering beliefs.
A sample script // with commentary
👋👋👋 [their name] // it’s safe
I saw you just picked up the [subject] ticket, // empathy
and I was curious about that [technology|domain|problem] // it’s safe: exploration, not competition or judgement
It looks fun // win for them: working together isn’t going to be a burden
Want to work on it together for a bit before I pick up my next ticket? // low time commitment + they’re in control
All throughout, the specific words are less important than the meaning and beliefs they convey.
As long as you have positive intentions, don’t burn bridges, and take feedback well, your coworkers will likely be open to continue working with you.
Feel free to try out the script and vary up the verbiage in your own unique way to empower your team to pair 😊
But the script doesn’t mention pairing at all!
“Pairing” is engineering jargon for a particular way of “working together.”
When we use simple words we’re more likely to be understood.
Familiar words are especially useful if a coworker is used to working alone and working together may be a big ask of them.
That way, the ask is easier because jargon doesn’t get in the way.
But they still said no…
Time to flex those empathy and problem-solving muscles 💪
No’s are normal
They’re an expression of people’s agency, and that’s a good thing.
A no is the start of a negotiation.
It gives the opportunity to discover what can be a mutually agreeable outcome.
Worst case, you can go back to working alone and ask to work together again later (in a different way).
Asking again
Remember, it’s “no big deal” if someone responds with “no” to your request.
Listen
In telling you “no,” your coworker likely gave you a reason for their hesitation.
If you address that objection in your next request, you show empathy and help your coworkers see your request as advancing their self-interests.
Don’t be needy
You both are competent and self-sufficient in that you are able to work on your own.
Conveying that underlying belief in your request helps others to feel comfortable considering your request.
Otherwise, you risk sounding needy (and that’s uncomfortable to deal with).
Consider other pairs
If you can’t reasonably solve the objection behind the “no,” it may be time to ask someone else.
Some people are more open than others to trying new things.
Starting to pair with early adopters first can help de-risk pairing and establish it as a social norm.
In case of “Yes”
Congrats! Now you get to work together on that ticket you agreed on!
But we’ve never paired before
That’s alright, you don’t need a formal structure to your working session to get great results!
In the meanwhile, some guidelines
Keep it informal. Structuring the pairing session can wait till next time.
Aim to make the session engaging and productive, so you’re both contributing.
Be aware of energy levels, suggest a break if you or your pair feels tired.
Now that you have the tools to start a conversation around pairing, talk to a coworker, see if they want to try it out!
When you do, comment below and share your experience! The more different perspectives we share, the more we can learn from each other.
If you’d like to join a growing culture of pairing at Clover, apply on our careers page!
Comments
- According to Daniel Kahneman’s book, Thinking Fast and Slow, System 1 (fast) thinking makes intuitive decisions by pattern-matching against things that the brain already knows. System 2 (slow) thinking is used in rational and deliberate decision making. However, System 2 is energy-intensive and people will often default to System 1 instead because it’s easier. However, System 1 can yield incorrect answers when it doesn’t have enough information to answer a given question.
Works Cited
Cockburn, Alistair, and Laurie Williams. “Extreme Programming Explained.” Extreme Programming Explained, by Kent Beck and Cynthia Andres, Addison-Wesley, 2006, pp. 223–243.
PS: Keep on the lookout for part 2 of this blog for a look into how to get the most out of your pairing sessions!
