Austin Vance is the CEO of Focused Labs. For the past eight years, he has intentionally only worked for companies that pair program, including a stretch as director of Chicago labs at Pivotal.
Pair programming introduces fresh perspectives to coding problems and spreads knowledge throughout organizations, but doing it well takes practice. Pairs can easily fall victim to power imbalances if one developer does a majority of the work while the other developer is sidelined. How can developers avoid bad pairing habits, and are there ways to save troubled pair relationships?
Vance shared five strategies for building successful pair-programming relationships: building up junior developers’ technical skills, setting timers to ensure equal time at the keyboard, rotating partners often, avoiding pair marriages and doing pair retros.
When a junior developer is pairing with a senior developer and feeling sidelined, what can they do to make the experience better for themselves?
One of the things I did when I first started pairing as a junior was do the stories solo at home, or sketch out the features that I was going to do the next day with my pair and actually do them. And then I would just throw that code away. So I came to the pair-programming session with enough context. Even though I might be junior, it helped me have opinions I can present, versus having someone who’s more senior just tell me where things should go. It let me contribute during the pairing session at a higher level. We were having conversations about the structure and design of the software, because I’d gone through production at least once.
“Even though I might be junior, it helped me have opinions I can present, versus having someone who’s more senior just tell me where things should go.”
I mean, not all of it — but I have to be like, “Alright, I don’t really understand React,” and so I’ll go home and figure out how to do React validations. I know we’re going to validate that this is a number, and that a date is within a range and a couple other things, so I’ll go home and make sure that I understand how to do those things. After that, I was able to come to the pair with a stronger understanding of how to implement, and then we were able to talk about design.
How junior were you when you used this strategy?
I was pretty much right out of college. I would do it when I was new to something, because as I would start to build up comfort, I just didn’t need to do it as much. But then I would drop into a new thing. So then I would go back to that, until I started to build a foundational knowledge of what’s required to be a software developer in a full-stack environment.
What other strategies would you use as a junior developer?
Pair programming to me is two people equally contributing to the production of software. And the key to that is they need to somehow figure out how they are equal contributors. I might not have been an equal contributor when it came to Java, but I could use patterns and philosophies and knowledge to become an equal contributor in terms of how we should structure or design code — or talk about it.
I love to read, so I saw it as my obligation to try to learn as quickly as I could. I would ask my pair for a good book recommendation about Java, and then I would actually read the book. I would try to show them that I was learning, because I didn’t want them to get frustrated — sometimes that happens with senior developers pairing with very junior ones. I was trying to apply stuff from the book that they would give me in our pairing session the next day or the next week.
“We use chess timers, especially when we have senior and junior people trying to pair together, to ensure near equal time on the keyboard.”
What can senior developers do to improve the relationship?
It’s the responsibility of the senior person to identify valuable contributions from someone who lacks the tactical skills. They might not know Java, but they can still think through the logic of how things should be structured or how they should be implemented.
A really important one is making sure you’re not just hogging the keyboard. At Focused Labs, we use chess timers, especially when we have senior and junior people trying to pair together, to ensure near equal time on the keyboard. So, if it’s an eight-hour pairing session, we set four hours on each side of the timer, and we’ll check in at lunch and ask, “Why does a senior developer have an hour more keyboard time than a junior?”
How can senior developers identify valuable contributions from a junior developer?
It’s a practice in empathy and patience. Pair programming is a skill, and when someone starts to pair program, they don’t know how to do it, and it’s exhausting.
The empathy, patience and communication required during a real pair-programming session is just a muscle that a lot of developers haven’t exercised. When someone who’s an experienced programmer is pairing with someone, they know how to share the contribution — and that’s the skill they develop over time.
We rotate pairs every day. I might be pairing with a senior developer today, and then tomorrow I might be pairing with someone who has the same level of experience I have.
“If two people are pairing together exclusively for a significant amount of time — six to eight weeks or more — they stop pairing and they become kind of one hive mind.”
It sounds like you don’t really try to pair up people who would work well together.
We do try to pair up people who will work well together, but we do that during our hiring process. We assume that our company is full of talented, passionate, empathetic and curious individuals who want to pair, regardless of their professional experience. They want to pair, and they’re driven to write better software with people. Sometimes, yeah, personalities don’t click, but if there are two people in our company who can’t get along — they just become completely counterproductive — we probably had a core value miss.
The other thing is we really, really try to avoid pair marriages. If two people are pairing together exclusively for a significant amount of time — six to eight weeks or more — they stop pairing and they become kind of one hive mind.
Are there specific strategies Focused Labs uses to practice empathy?
The common practice at Focused Labs is ending every day with a pair retro. Literally at 4:45 p.m., we stop writing code and spend 10 minutes giving each other actionable feedback.
Those pair retros are pretty superficial the first few weeks people do them, but, as pairs and the team build trust in each other, they become exceptionally valuable, and people actually crave them.
Really good pairing is a high-trust experience — I may not be asking questions, but instead giving feedback. Instead of me saying, “Did I do well today,” which is a really bad way for me to get any feedback, I would ask about something specific, like: “Do you feel like the design we used for these classes make sense? Do you see where I was coming from here?”
“Really good pairing is a high-trust experience — I may not be asking questions, but instead giving feedback.”
And the other person might say: “No, I really tried to give you feedback while we were pairing, but you were just on a roll. You didn’t hear me.”
That feedback session becomes an open conversation where you can pull your head up out of the sand, look down on the day and say, “OK, what went well and what didn’t go well?”
Learning to pair program is just another part of learning how to be a productive, empathetic and collaborative software developer. Being able to communicate and articulate technical problems like someone who is pair programming is a really valuable skill.
