Most of us have heard of it and most of us have used it: pair programming.
In the good old pre-covid days, pair programming involved two developers working simultaneously on the same machine. Nowadays, we tend to make it work with two separate computers, in two separate locations with the help of screen sharing but the principle remains the same. One developer, the driver, should write code while the second developer, the navigator, reviews the typed code in real time. Those roles should be changed frequently in order to keep the dynamic of the pairing session up.
The idea behind this approach is that a higher output is being generated since teammates will be working together to solve an issue rather than working in silos. Furthermore, the constant communication in the pair allows to find the best solution, share knowledge between both parties and therefore quickly move through faced challenges.
Pairing up can be more than just working on a ticket. It gives team members the opportunity to catch up and talk about their lives outside of work. The social aspect of it shouldn't be neglected, especially now that companies are shifting more and more towards remote work and engineers are getting less and less contact with their teammates.
You know the old saying, two heads are better than one. You should be able to freely share and discuss your thoughts and ideas on how to solve a problem. This will allow you to see the problem more clearly and to pool the knowledge of both parties to get the best outcome possible.
The knowledge sharing that takes place during those sessions is another important aspect of pair programming. It will allow you to either learn or teach coding practices and how to approach and handle problems from another perspective. This will not only increase the efficiency but also the innovation and the code base knowledge while decreasing the silo knowledge within the team.
Last but not least, being on "the same skill level" is not a requirement for pair programming. Pairing up a junior developer with a senior developer will benefit either of them. The junior developer will gain a significant amount of industry knowledge while the senior developer will be rewarded with a teaching experience while sharpening his/her competence to critically think about solutions.
Until now we only spoke about the advantages of pair programming, but overdoing it can lead to inefficiency. Constantly pairing up, even for the smallest tasks and the tiniest bug fixes will lead to the navigator being left out. The communication will be non-existent since the implementation will be straight forward.
A higher output would be generated if both developers would work on different tasks at the same time and not in a pair.
Unlike other methods of in-person collaboration, pair programming works really well in a remote context. You don't lose anything of the pairing experience, you may even find it more effective.
Use the advantage of not physically sitting next to your colleague. Thanks to screen sharing you will have more control of what you are looking at instead of working on one persons's screen.
Working in an isolated, remote environment is a great experience when one is "in the zone" but having no one to talk to when you really linger on an issue makes the whole experience more difficult and frustrating.
When a task is giving you a hard time and you are not able to generate any output or to create some sort of progress on it, it is time to pair up. Do not be afraid to ask for help.
Keep in mind that anyone can benefit from pairing up when being stuck on a problem.
No one likes to waste their time, this is why every meeting should have an agenda and a scheduled pair programming session is no exception to the rule.
Do not spend the first 15 minutes of the session deciding on what to work on or going through several tickets in order to understand the problem to tackle.
Set goals or expectations (this can be as simple as "let's discuss our options and decide on what path to take"), both developers should be on the same page about what to do and about what to focus on during the session.
Do not be afraid to freely and openly speak your mind. Even if you say something wrong it helps the process, you will tackle the problem more quickly. By being corrected, a new idea may be sparked by you or your partner which will ultimately lead to a solution.
Bounce of each other ideas and pool your knowledge in order to get the best outcome.
Several IDEs and text editors have tools dedicated to remote pair programming. Do yourself a favor and use them. It will give you more interaction than through screen sharing alone and therefore making the whole experience more enjoyable.
Here are some tools and plugins:
Being a good pair is not easy, regardless of your skill level. Do yourself a favor and finish your pairing session with a short retro in order to understand what worked well, what did not work and how you could improve your future sessions.