Software Engineering relies heavily on communication with others; teammates, product owners, designers, engineering managers, stakeholders. Yet so often we are trained to work and think alone. This is a shame because working together can lead to higher quality code, a better product, and — in the end — a happier end user.
Software Engineers can collaborate in many ways and forms. One of them is Pair Programming. Pair programming is a software development technique where two developers work together on one machine.
Though this sounds easy, it is not that simple. Pair programming involves a lot of communication and collaboration. It requires empathy and interpersonal skills and it can be difficult to manage a successful session. Pairing is an amazing tool, but it is a tool that we need to practice together before we can reap its benefits.
Let’s go over some ways to learn how to think together.
Set a clear goal and remember it
At the start of a pairing session, you need to discuss the scope of the session. What is it you want to achieve? When is that goal met? How much time do we want to spend? Make it clear for both of you what it is you want to get out of the session before you start.
Your way is not the only way
There are thousands of ways to look at a problem, implement code, or debug something. The key is that we must never think our way is the only correct way. Pairing is not a race where only one person can win. You both want to solve a problem, which is finishing the task you’re working on. You’re both on the same team. Take time to analyze your colleague’s solution before pushing yours onto them.
Be aware of the knowledge gap
One of my early pairing experiences was with a programmer who was much better than me. They bulldozed through the problem and seemed to have forgotten there was a huge knowledge gap between us. Seeing this much more experienced programmer taking up all the space made me feel intimidated and I got scared to speak up, ask questions, and share ideas.
Though it’s understandable that I shut down, it’s unnecessary. I learned later on that — when my pair has more experience on a topic — asking questions is beneficial for both of you. It can lead to fruitful discussions and better solutions. Even though your co-worker has more experience, explaining certain topics is just as valuable to them as it is to you.
When you’re the more experienced one in a pair, don’t assume that the other person can’t contribute. You might be wearing blinders when approaching a problem, and a different view can lead to a better solution.
Reflect
Pair programming can be mentally exhausting and draining. Reflect during the session to assess if the pace is manageable and sustainable. If it’s not, adjust accordingly.
When we learn how to explain ourselves, work well together, listen actively and treat each other with respect and kindness, we can get the most out of pair programming. It’s just a skill that we need to learn, that’s all.
Latest comments (4)
Baffles me why any company advocates pair programming. In my experience it's worse than useless and a sure-fire way to reduce productivity
Are there reasons why you feel like that? (I'm curious to understand because I find it useful. And I like getting opinions that are not the same as mine. This is usually a good opportunity to learn.)
In my opinion, pair programming should not be a default. But it I find it useful for:
Some also argue that it can replace code reviews because it the review is done while the code is being written. I kind of see their point but I'm not convinced yet.
But I pair programming done badly with no discussion between the pair. In this case, I would agree that it is not the best use of time. But I would not call it pair programming if one person of the pair is not participating.
One problem of pair programming - amongst others - is that it favours mainly one type of person. As a strongly introverted person you won't get much value out of me in a pair session. I'll just shut down within minutes when overhelmed by a overcommunicative other, or be bored to death by slow progress compared to doing it myself. Don't get me wrong, I can and love working in a great team, but please, split communication and coding into different tasks. (As a side note... this is also wrong with coding interviews: it alienates whole groups of people for no good reason)
It just plain doesn't work. It's like either having two people drive a car at the same time, or somebody constantly interrupting your thought processes, nagging you, and preventing you ever getting into the zone.
Programming is ultimately a solitary activity, all about converting your own thoughts into functioning code - akin to an artist translating his ideas onto canvas. Everyone has their own style and their own methods.
Discussing ideas is obviously fine and can often be beneficial, but it really does not help during the activity of writing code.