Pair programming
Hello! I’m Hanna, a frontend developer in Checkout tribe. Recently, in addition to adding new features and improving the Payment flow, our team is focused on stability, quality and knowledge sharing. We are focusing more and more on inculcating a “stability-based” mindset, and that is why I wanted to share my thoughts on the topic 😁
Recently, I pair programmed with a colleague on a task. We completed it, and it came out ok, but I felt like something was not quite right. Maybe something was off with our communication, way of work, …, I don’t know for sure. Then I thought: “Hmm, pair programming is well-known practice, but I don’t know anything about it 😅 But why is it so rare in practice? Maybe it’s undervalued? Maybe we can have a lot of benefits from it? But how can we reap all the benefits?” As you can see, I had a lot of questions and started a small investigation.
In this article I have gathered common questions about pair programming and the answers to them. I hope it can help someone understand the essence of pair programming and improve the quality of their work😁
Why does pair programming look so scary?
Too expensive? ⬇️ First, pair programming seems expensive. When people hear about pair programming, their first thought is: “If we double the number of people to develop one piece of code we will double our expenses🤔 “. That why pair programming can be considered as an ineffective way of work from an economics perspective.
In reality the cost of resources is only 15% higher. But why? As shown in research:
- together the pairs only spent about 15% more time on the program than the individuals
- significantly, the resulting pairs’ code has about 15% fewer defects
- the cost of detecting and fixing defects detected in the released product can be very high in terms of money and time for PM/QA/Engineer departments. And here we see how 15% increase of programming time can be justified on purely economic grounds.
Leave me alone😐 The second reason of “scary” pair programming is that programming has traditionally been taught and practiced as a solitary activity. A lot of engineers has their own “specific” way of programming: in a dark room, with music or whatever else. When it comes to working in a pair or a group, people feel out of their comfort zone.
But researches shows that people who worked in pairs enjoyed their work much more than when they work alone. Those who started practicing pair programming didn’t want to return to solo programming.
Some of you can say: “I tried it and there was no success. We were so tired and stared together at the screen all day and we didn’t complete task; I did everything by myself; and many other issues 😣”. Most likely, something went wrong during your programming session. Later in this article you will find some tips which can help you to organize your work when pairing, so you will be satisfied with it 😏
Don’t touch it!🙅♀️ Many experienced programmers are very reluctant to program with another person. Some say their code is “personal,” or that another person would only slow them down.
One of the reasons why you shouldn’t be a fan of you code is that you never know if it’s perfect or not. One person usually can’t see all alternatives for a solution and can make imperfect decisions. Good code is simple, readable and understandable by the whole team😉
If you have some other reasons why you don’t like pair programming you can:
- read about benefits of pair programming below, so it will look more attractive to you
- check out the tips of good pair programming sessions, so you will have more knowledge about core concepts
- practice it!!! so you will understand that it’s not so scary and unpleasant as you thought before
Benefits of pair programming
Yeah, adjustment to pair programming can take some time, but it will pay off for sure!!
Product stability🔝 As mentioned before, the resulting code after pair programming contains 15% less defects than code after solo programming. It means: less time spent on investigation and defect fixes, happier users and much less stress in the team.
Code quality💎 Working in pairs there is a larger number of alternatives than a single programmer alone might have. This reduces the chances of selecting a bad plan. Also pair programming involves continues code review and coding standards are followed more accurately, corner cases are caught during development.
Onboarding / Learning / Knowledge Sharing👯♀️ Pair programming is perfect for onboarding. Why? The onboarding process can take a lot of time, especially when business logic is complicated. When it comes to their first task, a newcomer usually doesn’t know where to start, which places in the code need a little more love, and how to test properly. When you get a work buddy who shows you around and explains how things work, it makes it much easier to start developing and shipping features!
Since multiple people have familiarity with each piece of code, pair programming reduces bus-factor risk (“a Bus Factor defines the number of developers that are vital to a project. If something happens to them (they get hit by a bus), the project is in danger”). That means more stability and less chaos when half the team is on summer PTO 🌴.
Communication / Satisfaction / Motivation😍 Team members get to know each other better if they work in pairs. They get closer and have more things to talk about. This leads to a friendlier atmosphere.
Also, pair programming can solve issues with demotivation. A demotivated team can be a disaster for the business — the team members produce less and less work. The relationships change, and the communication is poor. The less-productive employees get easily distracted by non-work activities and they drag the rest of the team down.
How to start?
Pair programming doesn’t mean that 2 developers just sit together and try to write something. Such a strategy usually fails and has negative results.
Here you can find some general tips which can improve your programming session a lot!!
Choose your style 💃There are several popular styles of pair programming: Driver and Navigator (Driver is focussed on completing the tiny goal at hand, ignoring larger issues for the moment, Navigator reviews the code on-the-go, gives directions and shares thoughts. The navigator also has an eye on the larger issues, bugs, and makes notes of potential next steps or obstacle), Ping Pong (his technique embraces TDD and is perfect when you have a clearly defined task that can be implemented in a test-driven way), Strong-Style Pairing ( driver totally trusts the navigator and should be “comfortable with incomplete understanding”). You can find a lot of details about each style and choose what suits you more. From my point of view, the style can help you shape your work, and create a foundation for it since these methods were practiced by a lot of other programmers.
Plan🙋♀️Before programming together you need to understand how you will work on the problem. Firstly, you both should understand everything related to your task and be sure that you can start work on it. Secondly, you should discuss the problem: brain storm about different approaches, and present your ideas. Thirdly, come up with approximate plan of your work based on your solution (for example, create a To Do list, subtasks).
Time management ⏳ Have you ever been in situation when you code with someone for 8 hours, and you were so tired and after that you avoided pair programming? The problem is 8 hours. Working for a long time without breaks is very exhausting for any person. And here the pomodoro technique will help!! In short, you break the workday into 25-minute chunks separated by 5–10-minute breaks. These intervals are referred to as pomodoros. After about four pomodoros, you take a longer break of about 20 to 30 minutes. It will help keep you from getting tired of each other and to relax a little bit during work.
Plan your day 📅 Pairing requires a certain level of scheduling and calendar coordination. It is good practice to discuss how many hours you will spend on your programming session, check if you have other meetings, and be sure that everything will be prepared in case one person needs to continue working without the other person. If you don’t take the time to acknowledge and accommodate this, it will come back to haunt you later in the day.
Prepare workspace 👩💻 Not depending if you work from the office or remotely you need to prepare. If you work from the office, you need to prepare space, chairs,keyboards, and monitors. If you work remotely — sharing tools, audio, internet connection.
Mini Retros 🙆♀️ Progress is when your last session was better than previous one!! After a few sessions, discuss your work, problems you have faced, enhancements which can be applied, and you can even celebrate victories!! It will help build trust, have more satisfaction from working together and make your work life even better!
If we have good practices it’s also important to identify bad practices. It’s important to keep them in mind but to not do that 🙅♀️
Sleep 🥱 For pair programming activity is a must. In that case activity means an ability to listen and to hear. It helps to be focused on your task, to understand another person’s ideas, to provide your own, to improve your work as a pair.
Orders, management 👮♀️Try to avoid giving instructions such as “…and now type dot, map, open brackets, pass a callback which receives …”, it can be very annoying for your pairing partner.
Hurry 🏃♀️ When someone from pair just does their work without understanding what is going on it’s not a goal of pair programming. At the start you won’t know normal work speed of your partner. Spend time to discuss problem, analyze and understand it!
Impatience 😩If you see that you pair is doing something wrong, don’t interrupt him, wait for 5 seconds and only then ask. Sometimes 5 seconds is enough for person to understand that he did something wrong and to fix it by themself.
Silence 🤐 Silence is gold but not during work in pairs. Ask questions, ask for input, ask for feedback!
Whole day of pair programming ⌚Avoid it!! Check Time management ⏳ part from good practices section.
This was my small investigation about pair programming. I tried to cover main questions but each of them has a lot of nuances and additional details which would take more than one article to explore. But I hope that pair programming is more clear for you and you are inspired to use it😎
If you read the article in full, you deserve memes 😏
