Earlier this year, Betsy and I sat down and wrote down a few dozen types of dysfunctional behaviors we’ve experienced while pair programming, then sorted them into categories:
- Taking up too little space (ex: lost but not speaking up)
- Taking up too much space (ex: keyboard hog)
- Pair has left you behind (ex: they’re on their phone and you don’t know why)
- You’ve left your pair behind (ex: you’re tunnel visioned and typing without talking)
- Out of sync with pair (ex: over-correcting the other person’s typos)
Descriptions sorted into categories.... these looked a lot like programming smells! this was familiar territory! Programming smells are solved with recipes, and this was a pattern we could follow. We set out to create a recipe index, but quickly found that even a single recipe creation was impossible.
Here’s the thing. Programming smells and recipes work because they are scenarios that can be addressed without understanding the why. It doesn’t really matter why some code ended up with a primitive obsession, you shove that obsession into a new class and everything works out great. Like programming smells, dysfunctional pairing behaviors are an early warning system that indicate a change is warranted. But that’s where the similarity ends. People are much more complex than programs, and why a pairing problem is manifesting changes how to address it. If your pair seems unengaged, treating them as a problem to be solved will make them feel worse.
Instead of looking at unengagement and other pairing dysfunctions as smells, we should look at them as symptoms. Smells lead us to clean up an area. When you have a smelly house, you can clean it up room by room. Symptoms show a system not operating as expected. When you have a system that’s not working as expected, you have to understand the problem before you can start to address it.
Let’s take a deeper look at one of the pairing symptoms we identified: your pair seems unengaged. Here are just a few reasons why your pair might seem unengaged:
- Doesn’t understand what you’re doing in this moment
- Doesn’t understand the problem
- Doesn’t know how to contribute
- Doesn’t want to take up too much space
These are all really different reasons that could be behind the same symptom! Addressing pairing symptoms is kind of similar to addressing health symptoms: you’re more likely to be effective if you know what you’re treating. A few weeks ago I had a bad headache, and painkillers weren’t effective. It turned out my allergies were being really bad, and I needed allergy meds, not headache meds, to address my symptom and make the headache go away. In order to help your pair become engaged, you need to pick the right approach based on why they might not seem engaged.
If you have a good working relationship with your pair, you can probably stop and ask. Hey, you doing ok? you’re more distracted than usual. But if you don’t already have a lot of pre-existing trust in your relationship, it’s not that simple. Your pair might not trust you enough to talk with you about it.
How about picking a neutral-seeming action? Maybe you could suggest they drive? Even that might not go over so well. If you don’t know why your pair seems unengaged, asking them to drive might not address the symptom. What if the cause was that they weren’t sure what you were doing and were scared to ask? And if your pair’s scared to ask, that’s an additional symptom as well..
It might seem silly for your pair to be scared. But your pair has had different life and education and career experiences leading up to your current pairing, and that may give them good reason to be scared:
- Poor past experience with speaking up
- Poor past experience with displaying ignorance
- Inexperience with pair programming
- Discomfort with the expected learning style (maybe your team does a code tour, but they feel more comfortable with sitting and reading on their own)
Betsy and I set out to find solutions to common pairing dysfunctions that we could share in a new workshop. What we learned is that there is no one-size-fits-all answer for any of it. How you and your pair have been encouraged and discouraged throughout your life and career have an enormous impact on how you will behave and respond while pairing. You don’t need to know anyone’s past to be a better pair for them in the present. You do need to know not everyone has had the same positive or negative past experiences you’ve had. When you carry that awareness with you into your interactions is when you can be a better pair.
If you liked this article, Cohere publishes a monthly Engineering Leadership newsletter and we would be delighted if you signed up!
Top comments (6)
Did I just read an ad?
Short answer? Yes. Long answer: Yeeeeessss?
Jennifer, Betsy, and I are programmers. While we are pretty good at bending computers to our whims and helping people and software teams be more effective, we are bad at content and community marketing.
The first part of this year, we did a lot of writing with no clear calls to action. Yet as much as we'd like to believe in the field of dreams, what we learned is that even if we build it, it doesn't mean people will come. About a month ago we sat down, looked at what we were doing and the impact it was having was and made a few changes:
My guess is we're probably a bit too far towards the strong call to action in this piece, but it's definitely a learning experience for us and we 100% appreciate this feedback!
I see a lot of these "advertorials" on Medium, which is one of the reasons I primarily read here and not there. But this is the first one I've seen here.
This site is supposed to be a place where devs can share their experiences with other devs. That's what I'm expecting when I read a post. So when I get to the bottom of a post and realize it's really an ad, I feel deceived.
We went through this whole thing before with deceptive banner ads and the internet decided to label them as ads.
Any chance you'd do something along the same line and prefix your posts with a "sponsored content" notice of some kind? I know that sounds risky but perhaps you'd consider doing it as an experiment? Run an A/B test on it?
Best of luck with your business.
Thanks again for your feedback! I've removed the call to action to sign up for the paid event and replaced it with a link to our newsletter.
Yes there is. Talk to each other!
It sure is no easy solution, but it is one. I bet, if I were to attend to one of your workshops, there is one key essence to be taken away: Create a safe space where everybody can express what's bothering him/her.
For sure! Talking with each other is a huge part of working through the tensions that arise when pairing.
That said, holy crap is it hard to talk through some of these tensions when there's significant power differentials.
I'm reminded of a time when I was working through a project inception with a team I was responsible for; and me (being the enthusiastic, charismatic, highly-experienced engineer) came in and started facilitating a mob programming session.
I noticed one of the most junior team members wasn't super engaged in the mob; which is a signal that something is up. I, being an idiot, asked them directly "Hey, I notice you're kind of checked out, everything OK?" Because, hey! Talking is the way to solve the problem! (Which it is!)
They responded with a "oh, no I'm fine!" and we carried on our way; and they made more efforts to be engaged.
But they had begun to slip into threat mode outside of the mobbing sessions. And I could tell. In our next one on one, I checked in to see how things were going, and I could tell that they were nervous. I went through my repertoire of rapport re-building skills, provided some specific, actionable, and compassionate reinforcing feedback about the things I saw they were doing well; and eventually they shared that they had found the mobbing experience jarring.
Why? Because in the past they had been terminated from a non-programming job because they weren't a "team player" and my innocent and enthusiastic question brought that experience back to the forefront of their mind. They had began performative "team-playering" in an attempt to alleviate a perceived, but non-existent threat.
I apologized and asked how I could do better in the future if I notice they are disengaged. Ultimately we decided that since we tended to have slack open and on, and it wasn't unusual for people to use their phones or laptops to look up docs or pull up past conversations while mobbing that I would send a DM checking in on them instead of asking that question in public.
In my opinion, me putting the spotlight on them in that moment was the wrong thing to do. Yes, it brought them into the mob, but at a cost to their ability to perceive the organization as acting in good faith. Not because we had done anything "wrong" per-se, but because I hadn't taken into account the background that particular team member had.
That teammate is on my list of people I am most proud of having worked with and would hire again in a heartbeat. Processing through the tension we experienced working together in a mob-programming context, even with my mis-step, built trust between us that allowed us to do some really amazing things as a team; and even today a few years later I look forward to the day when I get a chance to work with this person again.
So, yes. You are 100% right. Talking is amazing. Understanding the background context of the person you're pairing with and how to work with them is a way to make that conversation even more amazing.