7 Key Learnings from our Experience of Pair Programming
We love pair programming at Beamery as it is a great way to share knowledge and build a collaborative, effective engineering team.
At Beamery, pair programming is a vital practice in our collaboration toolbox. As a company, we believe strongly in communicating openly and pairing allows our engineers to collaborate, share knowledge and move more quickly than they can when working alone.
However, it’s important to remember that pairing is a tool that needs to be used in the right context, with the right intentions and expectations otherwise the benefits can be lost.
In this article, Manu and Ed from Team Quantum (one of a group of teams who own ‘candidate experiences’ at Beamery) take us through their experience of pairing in their team and explain what they’ve learned along the way.
🚀 About us
Ed: I joined Quantum back in March after completing Beamery’s engineering bootcamp. I was previously a Lead Product Manager at Beamery but this was my first role as a software engineer. Having been at the company for 2 years already, I had a good knowledge of Beamery and its core product, but I had (and still have) loads to learn as an engineer.
I was really fortunate to join a team where the culture was already strongly orientated towards pairing and collaborating. This was great for me as I needed a lot of hand-holding in the first few weeks as I found my feet with the new product area, the code and being an engineer for the first time.
Manu kindly agreed to be my ‘buddy’ in the team to help me get up to speed and, from my first day in Quantum, he and I teamed up to work together.
Manu: I started working as a mid-level software engineer at Beamery a year ago when the Quantum team was composed of only very senior engineers. I had been in a couple of tech companies before and I thought this would be a perfect opportunity to both learn from experienced engineers as well as share my knowledge with juniors.
I believe that working side-by-side with other engineers is the best way to grow as a professional and to build a great team atmosphere. Having regular pair programming sessions, either working on the same task or just helping others to debug an issue, is one of the main reasons why I became a software engineer. To me, all these activities help us bring out the best in each other and grow together whilst delivering for the company.
I feel lucky to have been able to apply this way of working and thinking in our team, especially once Ed joined us. I could see how fast he was learning and growing in just a few weeks, even though the environment we were working in was increasingly fast-paced.
🤝 Build a relationship first
In our experience, a good working relationship creates a strong foundation for effective pairing. If you’re pairing with someone but you don’t feel like you can offer advice, ask questions or interrupt them if you have a suggestion to make, you become merely an observer and the value of working together is lost.
Everyone will have different working and communication styles, but it’s important to build a connection that allows for open communication. This could begin with a quick, informal chat before you get started — something of a ‘getting to know you’ session. Even if you don’t hit it off straight away, there is always something to be gained from pairing with another engineer so it’s worth taking the time to get to know your pairing partner, understand how they work, their skill level and what they hope to get out of the experience.
Building empathy and trust allows both parties to speak openly without fear of causing offence, creating an environment for collaboration. To foster the most effective and collaborative environment, it is necessary to communicate openly, give and receive feedback, have empathy for one another and be vulnerable and risk being wrong.
These things don’t happen overnight and are built slowly over time as a team works together but that journey starts with a first step. Ultimately, the goal is to do the work and deliver for the team, the company and your customers — but there’s no reason why it can’t be fun at the same time!
🔗 Pair with new members of the team
When starting out as an engineer, a junior can feel like they’re not adding any value and worry that getting help and support from their seniors is distracting them from their work. However, without access to more senior engineers, juniors can very quickly become stuck.
Whilst this is a particular issue for juniors, it’s also true for any new member joining a team. Joining a new team can be quite challenging, especially when a project has already been started or a product is quite mature. There is always a period of learning or ‘ramping up’ as the new person familiarises themselves with people, the product and the codebase.
For busy teams, hoping that someone new will get up to speed and add value by themselves is often ineffective. At Beamery, we recognise that growth is a shared responsibility and so we ensure new engineers are paired, or ‘buddied up’, with more senior members of the team to guide them and promote their development from their first week. This creates an environment where new team members can get involved more quickly and make valuable contributions to the team’s work.
💭 Decide together on a pairing style
When pairing, we generally utilise the ‘driver / navigator’ approach whereby one person shares their screen and codes (the driver) whilst the other gives directions and provides suggestions (the navigator). Then, after a while, you swap roles. This approach is great as it allows the driver to practise their coding whilst it allows the navigator to think about potential issues, bugs and plan the next steps. With this method, we’ve found that it’s important to establish a couple of ‘rules’ to ensure the collaboration is effective.
It’s good practice for the navigator to apply a ‘5-second rule’ if they spot a typo or an error. Giving the driver the chance to correct their own mistake is far more helpful than interrupting them constantly and pointing out their errors. Often, the navigator will be aware of what they’ve done but sometimes it’s easy to overlook a typo, even with the help of linting and formatters.
There are variations in this style of pairing. For instance, for those at a similar skill level, working together jointly on a problem, it can sometimes feel more like a pair of navigators with one person driving. This can be helpful if one is testing functionality for the other, looking up documentation or simply providing alternative ideas to solve a problem.
We also look to over-communicate whilst pairing so that it’s clear what is happening, what the next step is and what kind of approach is being taken. This also makes it easier to ask questions as there’s already an ongoing dialogue, rather than awkward periods of silence.
For any of these tips to work well, as above, it’s important to build a relationship first and ensure you’ve created an environment open to collaboration. Pointing out a mistake or suggesting that you swap over can be difficult if you’re not yet comfortable with that person and you fear them taking offence — especially if you’re the more junior engineer — so having agreed practices ahead of time can help with this.
There are lots of styles of pairing — try out a few to see what works best for you. You could try ‘ping pong’ pairing where one person writes a failing test and the other writes the code to make it pass. Alternatively, the ‘tour guide’ might work best — where one engineer (usually the more senior of the two) takes the reins and codes while the junior engineer focuses on asking questions and learning from what’s happening.
⚙️ Get the tooling right
When pair programming in the same physical location, it’s necessary to prepare and figure out how it will be comfortable for both sides. We’ve found using second screens, ideally on the same desk, is ideal.
With the shift to more frequent working from home, remote pairing has become far more common than it was before the pandemic. Fortunately, video conferencing and screen-sharing tools which allow both engineers to see and control each other’s machines, have made this a great experience. Also, online visualisation tools can be helpful substitutes for a piece of paper or a whiteboard to sketch ideas or explain a solution.
When pairing remotely, we’ve found that it’s better to have your video on as this improves the communication considerably, allowing you to pick up on visual cues, behaviours and expressions to help communicate.
Whilst there are certainly benefits to remote pairing, we’ve found that it’s very easy to lose focus and multitask, particularly if you’re not ‘driving’. It’s important to avoid this by minimising distractions, taking frequent breaks and reserving a specific block of time each day for pairing. When it is necessary to multitask or answer a Slack message, be sure to over-communicate with your partner and ensure focus isn’t lost.
💡 Rotate within the team and don’t be limited to pairs
Pairing with the same person all the time can be great, but it can also be tiring. We’ve found that pairing and interacting with a wide variety of people is ideal. By pairing up with a mixture of people, it’s possible to learn about, or help others with, more topics and techniques. It also enables you to build a better relationship with your team members and see how different people communicate.
As a team, we sometimes find ourselves ‘mob’ or group programming with up to 4 or 5 people. It’s rarely organised ahead of time, but we’ll often swarm together on a problem — either pulling people into a call or organising it ad hoc at our morning stand-up.
‘Mobbing’ is a great way to share and pool knowledge quickly and having multiple eyes on a thorny production bug can be very helpful. It can also be a useful technique to ensure engineers are on the same page about a process change or a new technology as it is an efficient way to spread understanding in the team. We would caution this by saying mobbing should be used as the exception rather than the rule — it’s very costly for all team members to stop what they’re doing and work on a single problem together, and it will undoubtedly affect your team’s velocity.
🛑 Stop, take a break
Whatever your chosen style of pairing, we’ve found that it’s also critical to take breaks often. Pairing is tiring as it requires your full concentration for long periods of time, so after a while, your mind needs a rest. This extends to working in general of course (!) but it’s tricky to stop when two or more of you need to agree to have a break.
It can sometimes be hard to know when to stop, and some engineers will be more keen to ‘power through’ than others. Try setting a time limit, such as saying that you’ll switch after a certain period of time. Or you could try picking a specific task and plan to swap when you’ve implemented a certain piece of functionality or closed a particular ticket.
In our experience, we’ve found that working for around 45 mins to an hour, then having a break, and swapping when you come back together works well. Everyone is different though, so try out a few different approaches to see what your team prefers.
If you don’t take breaks, you can quickly become less productive, more prone to making mistakes or you might just get annoyed with each other — it’s really important!
🚦 Know when to pair and when not to
Whilst pairing has many benefits, it’s important to be mindful of when it’s best to pair and when it’s best to work independently.
It’s not possible to pair all day and, in practice, engineers have many tasks, like meetings and self-learning, to do alongside coding. It’s necessary to strike a balance and one way to achieve this is by setting and sticking to core pairing hours.
There will be times when you are pairing that you’ll reach a dead end where neither person knows how best to proceed. Researching and experimenting together can sometimes be frustrating as people explore things in different ways and at different paces. In these situations, agree on the different questions to be answered then split up to do individual investigations.
Sometimes it’s necessary to deliver more quickly for a customer or for the business, and pair programming limits the number of tasks a team can work on in parallel. In this case, pairing can temporarily take a back seat but it’s important to reflect in a retrospective to ensure that any knowledge sharing that is required is acted upon.
For a junior engineer, it can be fantastic to pair up with senior engineers when starting out as it has the ability to greatly accelerate your development. However, as a junior’s confidence builds, pairing should be mixed with working on tasks independently to allow them to take ownership of their work. It’s still crucial to get feedback but this can be via comments and peer reviews.
🧠 Two heads are better than one
There should always be space for independent working but we firmly believe that pair programming enables us to share ideas, collaborate and work more effectively as a team.
Pairing is great for sharing knowledge and spreading the ownership of code, and it is particularly important for juniors or new members of the team. Disseminating knowledge is not only great for each individual’s development, it also ensures that there are no single points of failure in the team, where only one person knows how something works. More experienced engineers benefit from explaining the ‘why’ behind each block of code and it helps consolidate their knowledge and practice and improve their teaching techniques.
Having more than one pair of eyes on a problem can bring a diversity of thinking, giving a chance for different ideas of perspectives to be heard. It can often be useful to think about multiple solutions before charging ahead with the first one you think of. It’s more like an extended brainstorming process where multiple ideas and solutions are explored.
The practice reminds you that your code won’t just be seen by you and that it is important that what you write is clean and understandable to others. You also get the added benefit of your code being reviewed as you type it. Particularly for complex or large tasks, this really takes the onus off the reviewer who comes into a big PR cold and has to try and work out what you’ve done.
Overall, pairing leads to better outcomes — with higher quality code as well as improved coordination and collaboration between team members.
🤔 What’s next
Beamery is looking for Software Engineers Front & Back Mid/Senior/Director, SRE Platform Engineers, Engineering Managers, Tech Leads, Product Operations/Managers/Designers across all levels, and even more roles across London, Remote & Berlin! To join us — Learn more HERE!
Written by Ed Halliwell & Manuel Valles
