A Conversation with my Former Self on Pair Programming
I spent approximately the last two years pair programming full time. In any interaction between two people, information surfaces about both participants, whether or not they’re trying to reveal anything. There were many pairings when I got frustrated and blamed my pair for that frustration.
On my first project, you could hear me say:
“He goofs off too much.”
“She doesn’t know enough Ruby. I feel like we’re going too slowly.”
“He doesn’t respect sustainable coding practices enough.”
I have news for you, young Eric. While these statements reflected qualities of your team, they also reflected your impatience and lack of communication skill too. If I could go back and talk to myself during these times. I would have the following responses:
“It’s on you to call him out on goofing off. He’s coming from a different background from you. Maybe where he’s been, that was acceptable.”
There’s a marked shift in perspective with this statement. It’s turning the complaint into a call-to-action. In addition to responding to the frustration with “what’s next,” it’s a reminder to color my opinions with empathy. I could talk about the golden rule, or karma, or something similar to argue that the empathetic view is morally superior. Instead, I’ll just make the completely practical argument: it’s tactically superior to take an empathetic view of your team. Any form of criticism can be seen as a personal attack, so the criticizer can improve his chances of being heard by taking care to separate the person from his actions.
There’s also the possibility that my former self could lighten up and goof off a bit more. But I would just silently think this to myself.
“At some point you didn’t know that much Ruby either. Give your team members the patience you would appreciate.”
I see this complaint as more legitimate for a person new to pair programming. There is a perceived slowdown in development going from soloing to pairing with someone less technically skilled. Still, these frustrations can be worthwhile to a team. They are short term losses for longer term gains in higher quality ramp up. [1] Of course, there isn’t always a long term to consider.[2]
“Explain why the sustainable coding practices are important. If you can’t do that, maybe you should question whether they’re actually beneficial.”
This is the most important takeaway I’ve gotten from pairing. In the software industry, cargo culting is rampant. Projects can vary so much, so it’s hard to scientifically demonstrate that one processes is superior to another, even in some specific situations. I have absolutely cargo culted ideas before, and I likely am cargo culting some ideas still. Cargo culting is hard to see within myself; there are no clear indicators. However, I’ve found that difficulty explaining and selling an idea is to cargo culting as smoke is to fire.
These are actual complaints I had about people I worked with on my first project. To be fair to them, I think I could tolerate these behaviors in smaller doses. Such a team balance is workable, but it’s a local minima–far from ideal. Full time pairing dialed up how much I had to deal with team members in ways that I found uncomfortable, though. Pairing was a catalyst for maturity in me. It forced my hand to learn how to address issues with team members instead of trying to ignore them. That’s my umbrella takeaway for my younger self: look to resolve issues instead of just getting past them.
Notes
[1] I’ve also been in the shoes of the new developer. It felt daunting, and it was hard to ask for help. Sometimes I didn’t even know the right questions to ask. Pairing won’t close these knowledge gaps overnight, but it opens the door to asking more broad questions along the lines of “I don’t understand what’s going on here, could you explain it a bit?”
[2] On my last project, I found myself similarly paired with a green developer. She was unfamiliar with the language and framework we were using. She was enthusiastic to pair, but pairing did slow down the team. In this project, timelines were also tight.
At some point, I had to have the tough conversation with the stakeholders: “I’d like to pair with the new developer more, but with our tight timeline, there’s going to be a sacrifice in scope to ramp her up.” I think there’s value in having mature conversations of this nature–both with developers on a team and the business stakeholders who might have unrealistic expectations about scaling and the work output of the team.