Pair Programming at Spark Networks
At Spark Networks we like to use the best tools for the job. This means our tech stack uses a wide variety of technologies across our many dating platforms. Understanding how these technologies work and how they interact with each other is the first challenge new employees face when joining one of the development teams.
The technologies we employ in our products are massively varied. They cover services written in Java, Golang, PhP and NodeJS. They’re also accessed from native mobile apps or from our web clients such as Angular and React, to name a few. We don’t expect new team members to be experienced in all these technologies, but we do expect that the required knowledge can be shared across the team. To ensure this, one of the techniques our team uses is Pair Programming.
Let’s take a closer look at what Pair Programming is, and some of the pros and cons associated with this approach. We’ll also share a few handy tips based on our experience with it.
What is Pair Programming
Pair Programming is a simple technique – it’s about two developers working together. One person is the “driver”, or rather the developer writing the code. They’re accompanied by the “navigator”, the developer who’s constantly reviewing the code as it’s being written.
How does Pair Programming help with onboarding and sharing knowledge across the team?
Since you have two people working together, they’ll be talking about the task at hand and sharing their ideas on how to solve it. If someone has just joined the development team, it would be ideal to have them as the driver doing the coding, even though they’re fresh to Spark. This creates engagement from the get-go
In this situation, the navigator should be someone with more experience so they can support the new joiner. For example, they can explain the problem they’re solving and talk about the systems they’re interacting with. They can also guide the new employee towards a possible solution and answer any questions that might arise. The navigator’s support is very important as it boosts the new member’s confidence. By encouraging positive communication between the pair, it’s possible to drive engagement and confidence. Couple this with a hands-on approach and you have a great way to learn new skills.
With pairing it’s possible to leverage skills between two people. This approach can also be extended to the whole team too. Another good practice agile teams use is switching pairs every now and then. With pair-switching in the development team, knowledge is shared within the group.
It also hones soft skills as people learn how to work with each other and gain a better idea of their strengths and development areas. It also makes it easier to ask colleagues for tips. Thus, pairing can be useful for team-building efforts.
Other Benefits of Pair Programming
Besides leveraging skills and creating bonds within the team, Pair Programming also has many other benefits. Another major positive is increasing the “Bus Factor” (aka the “Truck Factor”). This is a deadpan term to express the risk of losing employees along the way who may be integral to keeping a project on course. The more people that know how a given project works, and how to build the necessary solutions, the better.
When the team gets used to pairing and learns how to work well with each other, better discussions and improved confidence are the byproduct. This can lead to the following:
- Better solution design
- Creativity and brainstorming
- Better test scenarios
- Improved morale
Unfortunately, even though Pair Programming is a simple technique with many benefits, Pair Programming itself is also a skill that developers must learn. It might even be harder than learning a new language or framework, or even more complicated than any technical challenge. After all, it’s a technique that involves people, their differences, and their personalities.
In short, it can get complicated. It’s important to understand that someone might be afflicted by peer pressure, might be having a bad day, or just doesn’t want to pair for any other reason. It’s important to be respectful and not to impose pairing, otherwise it could aggravate interpersonal problems and yield the reverse effects, leaving the team in a bad spot.
Fortunately, there’s a list of signals that we must bear in mind before initiating Pair Programming:
- Personality clashes
- Disagreements
- Skill valleys
- Distractions
- Bad communication and scheduling
Before introducing Pair Programming to the team, it’s a good idea to make sure that everyone understands their differences and that they can adapt to the situations to achieve their goals. Let’s take a closer look at some tips that might be useful to overcome these hurdles.
Pair Programming Tips
Always ask if the person is ready for a pairing session
It’s important that both are ready for the pairing session. They should both be in good spirits, free from distractions, and ready to have some good discussions.
If the pair is just starting to know each other, go slowly
If possible, start with a small task. Alternatively, have a quick session (around 25 minutes to an hour is perfect). That’s just enough time to finish a small piece of code and is a great way to get started.
Don’t dominate the session
It gets boring if just one person is having all the fun. It’s very important to not play both roles at the same time, so don’t be the driver and the navigator. Remember that both of you are doing their best to problem-solve together. Always be mindful that the pair must work together and should take turns by switching roles. It’s a good idea to switch after a small step is solved.
Be a good listener
One of the best benefits of a pairing session is achieving good design for solutions and sharing experiences. For that it’s important to foster good discussions and to listen to any constructive feedback from your colleagues.
Pairing Remotely
For times when almost all developers are working from home, here are some tips that will not only improve remote pairing, but also enhance the experience for all online meetings.
Cover the basics first
Make sure that you have a stable internet connection capable of streaming. It’s essential to share your screen if you are the driver of the session. This also means your navigator can see what’s going on and give you feedback.
It’s also important to have a distraction-free environment. This might be hard at home (especially if you have kids), so try to schedule quick pairings during peaceful intervals if it’s not possible to have a dedicated quiet room for working.
Mind the noise coming from your laptop fans
Developers usually have many processes running simultaneously on their machines, they’re all too familiar with the noise that comes with simultaneously compiling code, running tests, and running multiple docker containers – this heavy CPU usage makes laptop fans go crazy!
If you’re using the internal laptop microphone, it’s a good idea to switch to an external microphone. If you don’t have an external microphone, consider stopping all unnecessary processes to reduce CPU usage so the laptop can run quieter.
If you’re working from home, invest in a good mic
It’s great to pair, even when working from home. Since pairing sessions might take a long time, it’s a good idea to invest in a good microphone so people can hear you clearly with less background noise.
Speak up
It’s harder to capture small nuances in other people’s reactions when working remotely, so it’s crucial for the pair to clearly say that it’s time to switch roles, take a break, or to stop pairing.
Pairing should be effective and comfortable for both parties, if something is causing distractions or resulting in a lack of engagement, just tell your colleague.
When not to Pair
Even though pairing is great, there are situations when it doesn’t bring much to the table. These situations vary according to what the team is working on, as well as the team setup. In a team where all the members are full of heroic stories from ages of programming, some tasks might be trivial for them and they might not find it very effective to work on something simple. It would be wiser to have more people working on more complex challenges that would benefit from having more opinions.
Another situation where pairing is ineffective is when a person wants to perform a spike to test an assumption or research a new technology., For spikes, the code doesn’t need to be in pristine condition because it will be discarded and you’ll explain the results to your team later. Having another person involved here might hurt individual creativity by forcing another perspective on the matter.
As you can see, there’s much to be taken from Pair Programming. If you pay attention to your team’s setup, it can be an incredibly useful practice that drives team performance and strengthens bonds. We hope you find our quick take on Pair Programming interesting, good luck for your future pairing endeavors!
