Pair programming has become a popular way of developing the newest products and encouraging team members to share knowledge and grow together. Many of the world’s top enterprises adopt this innovative technique. Some of them with success and some of them with less expected results.
Before a company embrace pair programming its leaders and developers should get to know some basic knowledge about this approach. As a company that not only uses this practice on a daily basis but also implements pair programming in the customer’s engineering teams, we’ve answered to the commonly asked questions about this technique, its pros and cons, how to prepare a workstation for developers working in pairs, and if pair programming is good for everyone.
What is pair programming and how should it look like?
You can find various definitions, but most of them agree that pair programming is an agile software development technique that requires two developers working together on the same block of code, using one workstation. In these pairs, one programmer is becoming a “Driver” and the second one is known as a “Navigator”. Where they work together “Driver” manages a computer and writes code, whereas “Navigator” is supposed to check the written code, follow colleague’s job, and work on problems faced during implementation. When using the pair programming technique, programmers should discuss ongoing works, search for effective solutions, and support each other. What’s important, roles in a pair coding team should be changed during a workday as they are not assigned permanently.
How to prepare a workstation for pair programming?
The most important thing when designing a workstation comes to making it comfortable for both programmers. A desk for a pair should be properly larger than a desk for an employee working alone. And when two people work together for eight hours a day both need their own, dedicated space to build a comfort zone. A workstation for coding duo requires at least two monitors that displaying the same things, and a keyboard and mouse for each developer.
Teams that work remotely proved that pair programming can be done effectively even when collaborating developers do it at a distance. It’s important to equip these developers with a working gear that enables productive communication, and high-quality headphones are a must-have.
Here is a list of useful tools and resources for pair programming:
- Cloud IDEs: AWS Cloud9, Codenvy,
- Communication and screen sharing tools: Skype, Slack, Zoom, TeamViewer, Stride,
- Live Code Share Extensions: Atom Teletype/VSCode Live Share,
- GIT Scripts: pivotal-legacy/git_scripts.
Advantages and disadvantages of pair programming
And when pair programming delivers real value for companies that implemented this technique, the leaders responsible for adopting these practices in their teams have to be aware of its threats. Here are some of the most valuable pros of pair programming:
- Higher quality of designed solutions - more compound and more meaningful development for given tasks.
- Different views and perspectives regarding the same problem.
- Reduced risk of failure or making a mistake.
- Time and cost savings - software is delivered faster which decreases the costs of development.
- Agile and productive knowledge transfer in projects.
- Breaking down silos in projects - avoiding situations when only one person in a project owns key knowledge.
- Building stronger relationships among team members.
And here come some cons every company has to take into account:
- Dealing with distractions to individual comfort zones and independent working style.
- Personalized working environment - getting used to a non-standard way of doing a job.
- Common lack of convenience to not that obvious and innovative way of programming among developers used to works on their own.
- More demanding and exhausting way of work.
All of the disadvantages may result in rising discomfort and drops in productivity which sabotage the whole idea of pair programming and potential wins it could provide.
Was every developer born for pair programming?
Pair programming may not be that easy as it is often presented. This technique obligates developers to be communicative, conscientious and focused on the subject matter. For many coding professionals, the hardest part of programming in pairs comes to the necessity to adjust to the other person - her/his way of work, time, and individual habits.
People who value working on their own manner and their own comfort, need focus and quiet environment, or just avoiding too much engagement in communication, may find pair programming too demanding for them.
My experiences with pair programming
My experience with pair programming has started two years ago. The theory seemed reasonable, but I was a little bit skeptical and to be honest, I didn't believe in promised advantages. For me, it was rather a waste of time and resources when two developers work on the same problem at the same time.
At first, it was hard. I had to change my entire working routine and adjust to a colleague I was paired with. Actually, we both had to modify our working style, and we all know how difficult it is to change habits.
Adjusting to the new technique of doing my job influenced my time after work. I was more tired but at the same time, I felt that we had done a lot of good quality job. And step by step, it became easier as we got familiar with those practices. What was really encouraging - the result of our work and amount of new knowledge were insane.
Working at that level of focus is demanding and costs a lot of energy. So, having a break for 2 or 3 minutes, do some small talk about topics unrelated to problems you’re currently trying to solve, may result in a more productive attitude during the day. It’s also worth noting, that direct collaboration with one of my colleague gave me the opportunity to better get to know that person and having a good friend at work also improved my comfort.
After a few weeks, I’ve noticed all these advantages of pair programming that previously wasn’t that obvious to me. We’ve improved the quality of our work, and our solutions were well thought out. As a result, we’ve minimized the number of mistakes which significantly enriched our outcome. And then it has become clear for me that pair programming is not just a cool theory but an effective way of developing new solutions and useful tool for learning new things. And when it’s a challenging technique, maybe not for everyone, but for sure it’s worth giving it a try. Anyone can try it on his/her own and in case of any troubles get back to the previous way of doing the job.
To sum up all my experiences with pair programming, I have to admit that this technique definitely works and expect the simple tasks, it’s worth to use it every day.