This is a written version of a talk I did at our Engineering Forum. I talked about the intangible skills I wish I knew about pair programming. I think early-career folks will find these particularly useful as they work with more experienced engineers, because the content are my learnings mostly from when I was a junior engineer.
Pre-pairing - pairing - post-pairing
When I first started to pair program, I always thought about it as a single activity. But when I took a step back, I realise building a shared context is a prerequisite for good pair programming. Because pair programming is about working on a piece of code together.
What if we think about it as a three-step process? With a before and after, instead of thinking about pair programming as a single step.
Before pairing, we prepare and lay the groundwork to build a shared context. Make it as easy as possible for the other person to understand us. It can be as short as something like “I’m thinking to spend the first 15 mins to explore how the classes interact, then we can start by creating a method for X before we do Y”.
After pairing, we reflect upon what worked well and what didn’t for the pair. Think of it as a mini-retro.
Was the experience what you expected? What did you learn from the other person? Did both of you come to a better solution? Was there any point during the pairing you felt frustrated? What can you do to make the duo works better next time?
Be honest and speak your mind
This is cliche, I know. But being honest is easier said than done. Vocalising each of your thoughts is difficult. And it takes time to build the habit to do it consistently. Yet it is crucial in building a shared common understanding so both of you can contribute. And no one mind-read, it is part of your job to help your buddy to understand you.
One of the biggest challenges I had was that I constantly felt that I was crashing into the other person’s train of thought, and I’d hesitate to ask questions. For this, I found making transition explicit helps. For example, instead of jumping straight to my question, I’d say something like “Can we pause here for a moment?”, “Can we go back to a step before this and clarify
Every Person is different
Accommodate the individual differences. Putting this in the context of pair programming, it means playing into each of our strengths and learning to accommodate the diversity within the duo. One of the goals for pair programming is to reap the benefits from putting two heads together, and to do that, it’s worth thinking about how to make it as easy as possible for each of the individual to contribute. Some concrete examples I found useful to pay attention to are: the communication style, level of knowledge and way of thinking. Being aware of these helps me to be more empathic when communicating.
Some example prompts I use to learn about my buddy are:
- do they prefer to receive information in written form or verbally?
- do they like to have some more time alone to think things through first?
- do they respond better when we have a concrete plan?
And pair programming is a two-way street so I think this also ties into the previous point - be honest about what works for you and what doesn’t, otherwise your buddy wouldn’t know.
Have a routine
After finding out what works best for you and your pairing buddy, set up some structures so you can simply rinse and repeat what works well. It releases you from the pressure to optimise the process all the time, and saves you from following old habits that might not be as conductive for pair programming.
As a bonus, it’s a great way to make sure you take a break regularly and not get into rabbit hole, while excusing you from being the person who always asks for breaks!
- Building a shared context and common understanding is a prerequisite for pair programming.
- Honest communication is important. Find ways to do that even if it seems awkward at first.
- Respect and accomodate the individual differences.
- Pair Programming is a skill, and it takes time to build.
See you next time 👋