Pair programming can be an amazing way to collaborate and build quality software fast… or it can be hell. Here are 5 points why I like it so much (and why you should give it a try).
Naturally talkative.
For a chatterbox like myself, explaining every thought that comes to mind is simply the natural way to process information. Imagine being forced to do that for every change you introduce in your codebase. You can see why this can be hell for some people already, right?
Pair programming requires establishing trust, a relationship based on confidence and explicit agreements to be always constructive. With this in place, and a natural tendency to openness, getting into a flow state is as easy as enjoying a good conversation with a friend.
Feedback flows constantly.
You have to be very open to feedback and consciously not take it badly. There will be back-and-forth, you’re not in charge of deciding what to do and you will have to learn how to sell your ideas, how to explain them clearly and how to listen to yourself and build consensus to move forward.
Explain your thoughts in real time.
When I say you’re gonna be talking a lot, I’m not talking about gossip or what you did last weekend. The value of your constant flow of mind is understanding your thinking process and that’s something that you have to understand yourself before you start communicating it. You need to understand how you break down problems into subproblems, how you focus on the most important bit, how you test things, how you make sure that your changes are incremental and are building value, and how you address the trade-off that you make in a pragmatic way while aligning with the vision your team has. It’s not an easy thing. It’s not just talking out loud about anything. You will have to find the right frameworks to think clearly and communicate those thoughts clearly too.
On this, I recommend relying on an architecture that helps you break down problems clearly — ideally in a vertical way — and invest in thinking frameworks that allow you to understand things in a more structured way, and communication frameworks that allow you to articulate your thoughts clearly.
Learn the roles. You’re not a human linter.
It’s important to take the time to onboard into the process from a formal perspective. There are clear differences between the driver role and the navigator role, and you have to be agile on switching roles fast.
When driving, you want to be your best version of a technical mind. You’re taking the small decisions. You’re behind the wheel. You feel the clutch and shift gears, so to speak. When navigating, you set the direction. You are there to keep the goal in mind of the driver at all times. Your role is not to be a human linter or enforce premature optimizations, the same way that’s not your role as a Pull Request reviewer—but that’s another topic.
Building on top of that communication that you have set, you understand the decisions of the driver, the trade-offs that they are thinking about and you assess that these aligns with the long-term vision of the task, story, or project. You’re a part of the couple here, you don’t get the benefit of not being accountable for what’s being written, but when you’re driving, your mind is focused on a very short distance (think as “watching the road” = the code you’re now writing), while when you’re navigating your vision is on the destination.
Take pressure out of interviews.
Coming back to the perspective where this is hell, in the last point I’d like to introduce the similarities of a technical interview. In order to thrive in those, you don’t have to come up with the perfect solution out of a hat. Instead, you have to explain your thinking process in every decision, because your interviewer is interested in understanding that, not if you can implement a topological sort on a DAG in linear time.
For many people, pair programming can trigger the same level of anxiety and stress that they feel in technical interviews. I prefer to think of it from the opposite side: The skills you develop in pair programming help you build up muscle that is very useful when thinking about future interviews, and if you’re not interested in having interviews in the future, those skills can also help you explain better when mentoring and coaching, when sharing an idea to another team or company, when writing a blog post. It’s about finding structure that you find useful and that you can use to communicate ideas better. And that can never be a bad thing, right?