Programming is often seen as a lonely job. The image of the hacker in dark room is what people have witnessed through movies, but you know that the reality is something very different. Programming is a social job.
Developers are more productive when they feel inspired and work together with their team. This means giving developers tools and resources that help them better collaborate with other developers.
This can be achieved using a variety of tactics and one special methodology is pair programming. At first it looks like just another way to increase efficiency and productivity, but when developers pair with another colleague, besides producing code with fewer bugs, they build trust in the team.
It's true that pair programming can be intimidating for some developers. They don't like the idea of someone watching them code, they feel they are being judged, etc. But that's not how it works. In this post we'll be discussing the benefits, challenges, styles of pairing programming and some of the best practices.
So make sure you stick with the article till the end to get all your doubts cleared.
What is Pair Programming?
Pair programming is a programming methodology in which two (or more) programmers work side-by-side and collaborate together in real-time. There are many ways to do pair programming, one common format is having two roles: The Driver (host) and the Navigator (guest).
The driver is the developer who codes, talks as he/she works and shares their thoughts in real-time. As the "navigator," another developer watches the driver while they work. While the driver codes, the navigator comments, offers suggestions and can focus on the bigger picture. They naturally can (and should) switch between each other throughout the duration of the coding session.
One important point is that as the navigator is reviewing every line of code produced, this inspection enables the early detection of bugs and reduces the time reviewing code later. Actually we could say that pair programming is a way to do continuous code reviews.
Pair programming unlocks better collaboration, higher quality, better code, and more sustainable improvement in development practices.
Why Should You be Pair Programming?
Engineers definitely can work around the clock to push code into production and deliver features under tight deadlines. But how productive would that be if they are always working alone? The code will be more prone to technical debt, hidden bugs and performance issues. Solving these later may cost even more time and effort.
Pair programming isn't about producing more code, but knowledge sharing.
Code should be easy to read and concise so it behaves as expected and others can collaborate with you without adding more bugs. To make that possible, developers need to be able to communicate clearly the requirements and their intentions. This sounds simple, but those are real problems that pair programming can help to solve.
The quality of code produced by two developers working together improves, along with their mutual understanding of the codebase. In general, when two people can think about the same problem, they can create simpler and more efficient solutions while learning from each other.
What are the Benefits of Pair Programming?
- Fewer bugs: You know the saying, two heads are better than one. If the driver comes across an issue that prevents him/her from moving further, there will be an extra brain to help figure out the solution.
- Focused workflow: Focus on the work, and attention will increase. The pair will help one another remain focused on their work to create a productive session. The flow is more resilient to interruptions as one person handles the interruption, while the other keeps coding.
- Knowledge sharing: Pair programming is a great way for developers to learn from each other, independently on their experience level. Developers can have contact with different ways of thinking and approaches. Another element is pure codebase knowledge that is shared among the participants. People can explain the code, their intentions and they can discuss in real-time their decisions and ideas.
All mature software development teams should also consider the "bus factor." What happens to a project if one person is hit by a bus or has to leave suddenly? What about technical knowledge that is not easily accessible or would take too long to recover?
- Improves codes quality: Better code is possible by sharing best practices with partners. When you are part of a pair programming session, you work in a team. Both partners can use their experience and knowledge to solve problems quicker and in a better way.
- Improved team collaboration: Besides being able to learn from your colleagues, pair programming motivates partners to be more accountable and to produce better code.
- Less code reviews: While code reviews can be helpful specially when working asynchronously, pairing is better, allowing developers to be equally familiar with their code and the decisions made. Regularly swapping pairing partners helps maintain high levels of communication between all members of a team while reviewing the code in real-time.
- Get Stuck Less: It can often save you a lot of time if someone is there to direct you in the right direction. The navigator might help the driver move in the right direction when the driver seems to get stuck - and vice versa. This way, everyone wins, and problems get solved faster.
What are the Challenges of Pair Programming?
Although pair programming have many benefits, it has some challenges as well. Lack of focus, not switching roles, not having an agenda and just being rude with your partner are some of the problems you could face on a pair programming session.
Here are some traps you can easily avoid with your colleagues.
- Be a nice person.
Nobody likes working with rude people, just be nice with people that you are coding with. If you see that you are losing your patience for whatever reason, just ask for a break or don't say everything that comes on your mind.
- Have an objective.
What are you trying to achieve? Are you building a new feature? Debugging something? Be clear about your goals and the time you are going to commit to the pair programming session. You don't need to over plan it, just have a very basic milestone to accomplish is enough.
- Switch roles regularly.
This is a very easy trap to fall. You are feeling productive coding, your partner is happy and you keep going longer than originally planned. The issue you are going to start to be tired and your partner frustrated with their participation, but that will be too late to switch. Another big problem is that the knowledge is not equally shared when both developers are not given the opportunity to lead the action.
What are the Different Styles & Techniques of Pair Programming?
There are three main styles of pair programming:
- and ping-pong.
Driver-Navigator: This type of pair programming is looser than the Ping Pong Pattern. It is like two people driving in rally cars, one driving (coding) and the other navigating.
The navigator gives the driver instructions, and the driver can make corrections or request clarification. This is a good antidote to the anti-pattern, where the person typing controls the text.
It puts the other person in passive mode, and they can watch what is happening. Every 15 minutes or so, the driver and navigator can switch roles.
Ping-Pong: This type of pair programming can be used in conjunction with Test Driven Development. One person creates a test, and the other makes it pass.
This is because it is easy to take turns. Each member should alternate writing and passing tests.
Suppose the same person writes the tests all the time (often the less experienced or confident developer) and is constantly making the test pass (often more senior or more confident developers). In that case, this can lead to a Ping-Pong anti-pattern.
Unstructured: This type of pairing is common when there is no specific approach being used. This type of pairing is fluid, with the navigator and driver turning as it seems appropriate. This is style is also very good when you have more than 2 people participating. This freedom from a structure can make a coding session move faster.
Pair programming works best when each person brings something to the table. It's best to have the option to choose your pair programming partner. Find someone to fill in the knowledge gap or give you a new perspective.
What are the Best Practices of Pair Programming?
Although pair programming has many benefits, it is always best to know the best practices before you start coding sessions in your organization. Some of the best pair programming practices include:
- Pair up carefully: Make sure the developers can work well together without any problems. Or else, this will create a hostile work environment. Keep analyzing the results of pairs when they work together to understand better if they are best suited for each other or not.
- Switch often: Collaboration is great because each member brings their skills to the table. Create a culture that encourages sharing. The team members should be aware that they will be expected to spend equal time as navigator and driver, so they don't feel they have done less or more.
- Consistent Communication: Developers are unlikely to share their thoughts if there isn't communication. So both the team members must be communicating regularly and having healthy discussions about the project.
- Encourage Respect: Tensions can be seen flaring up when one of your team members feels ignored or picked on. You can help keep frustration at bay by setting some rules of respect from the beginning, including respect for ideas, the class, the roles, and the personal space.
- Take Breaks: No one can ever achieve any best results by working all the time continuously. Especially if you are working in a pair, you must set some rules for the breaks, and both should be comfortable with it.
Pair Programming is an effective methodology that has been used in software development for years and can improve team collaboration, knowledge sharing among other aspects of your work. It naturally has some challenges, but with a few pair programming tips, even your first pairing sessions will be a success.
If you are not already doing it, it's worth trying to do pair programming with your team. If it's your first time, also be sure to check the guide about starting to pair programming. This will make your work more enjoyable, encourage team communication, and of course, make your code better.
Duckly is a tool that helps you to have more productive pair programming sessions. You can share your code from any IDE and your colleagues can collaborate with you in real-time from their own IDE. Besides code sharing, Duckly allows you to share your terminal, screen and naturally talk. Duckly integrates audio and video calls so that you don't have to use multiple tools simultaneously.