First things first - what is pair programming?
Pair programming is a development practice in which two programmers work together in one workspace. It allows developers to learn from each other and improve code quality through knowledge sharing and discussion.
When and why should we use it?
For the difficult or most important parts of the software
You are more likely to make mistakes or to miss something in the more complex tasks. The second person could help to improve the quality of the code, by looking from a different perspective, reviewing your code live, or discussing a problem.
When recruiting new employees
Pair programming can be a great tool in the recruitment process. It allows you to easily verify both the technical and soft skills of the potential employee. However, it is worth remembering that this method may generate more stress in the candidate, which may adversely affect the result.
For the introduction of a new person to the project
It always takes a little time to adapt to a new project. If a person that is already in it, shows you the code and explains it to you, it can really increase the speed at which you will get accustomed to methodologies used in the project and increase your understanding of it.
When training technical and soft skills
Not only is this a good method for less advanced programmers to learn from more advanced programmers, but also more advanced programmers can learn from each other through discussion.
Variations of programming in pairs
There are three options for working in pairs based on the experience of the people involved:
- Newbie-newbie: Novice programmers can effectively resolve the hardest problems as a pair
- Expert–newbie: Useful as a teaching method, because an expert can share their knowledge easily
- Expert–expert: A good choice for creating very important parts of the software
The main techniques
There are quite a few types of pairings, some of which are:
- Driver-navigator: The most popular technique. One developer (“driver”) writes code while the other (“navigator”) reviews each line of code, asks questions and thinks ahead
- Backseat navigator: When we hit the wall while solving a problem, sometimes we don't see alternative ways. Then when someone looks at the problem from a different perspective, this canl be useful
- Tour Guide: A good way to implement a new programmer to the project. A developer who was already in the project codes and explains how the application works whilst a new developer observes and asks questions
- Ping-Pong: Perfect when we use Test-Driven Development (TDD) methodology, one programmer writes the tests while the other the code to be tested
- Unstructured: This is total freestyle without any patterns. It is effective if the developers trust each other
Advantages of pair programming
Here are some reasons why you should consider using this methodology:
- Mistakes are usually detected immediately
- Code is shorter and more qualitative
- Problems are resolved faster
- Developers learn from each other
- Programmers train their soft skills
- The whole team is more integrated
- The individual parts of the application don’t depend on one developer, which makes absence problematic
- It's easier to get to know the other developers
Is working in pairs free from disadvantages?
Like everything else, this kind of work also has its downsides:
- Coding is slower while discussing
- It can quickly becomes tiring
- Conflicts between developers may occur
- It can be difficult for introverted programmers
- The coder may feel stressed by being watched all the time
- The navigator may be reluctant to give feedback to the driver
- In stationary pair programming, problems may be caused by the difference in chair height, screen brightness, mouse, keyboard, or IDE
- It takes some time and practice to get used to it
Remote pair programming
These days we work remotely more often, but this is not an obstacle to working in pairs unless programmers work asynchronously.
Visual Studio Code has an awesome tool called “Live Share” which is Made by Microsoft. It allows you not only to see what another programmer is coding, but also we can code with them, talk, and share the terminals and ports. It makes work more comfortable and easier to get started.
What rules should be followed?
For pair programming to work, the following rules must be followed:
- Swap roles: Don't occupy the keyboard all the time, let your co-worker prove themselves
- Be nice: It's easier to work together in a relaxed atmosphere
- Use a familiar environment: Communication will be easier when both of you are comfortable
- Ask questions: Don't be afraid to ask questions
- Take a break: Take a 5-minute break every hour or when you need to
- Trust each other: Don't criticize in advance, be patient
- Control your ego: Your partner doesn’t criticize you, but your code, so listen to them and if you disagree, have a discussion
- Say I'm sorry: Sometimes we get carried away, or we unknowingly hurt someone, be mindful
- Don't be skeptical: If you have a negative approach, you will fail
- Think about your differences as something good: Don't take the difference in another person's thinking as a disadvantage, but as an advantage
- Watch the time: Long sessions lose their effectiveness and can tire you out. Sessions should last between 2 to 2.5 hours
- Change your partner: It is worth getting to know the skill sets of new people so you can learn from them
- Remember - you are a team: Everything you produce is a joint effort
So should I start my adventure with pair programming?
Well, it depends. Each case is different and the methods should be adapted to the problem, never the other way around.
If you think this might work for your situation, you should consider trying it out!
Top comments (6)
Have tried it a few times... it is quite simply the worst way of programming you can imagine - a sure-fire way to reduce productivity and irritate developers.
It's clearly a matter of situation. Most of the times I can't imagine working effectively and productively using pair programming technique, but there are situations in which it can be very handy.
Just imagine a scenario in which one developer is an expert in some technical matter and the other has some project-specific knowledge. Why not use pair programming to develop a feature that requires both of those? It surely will decrease the development time and everyone will learn something new.
Or maybe your are not matured enough to do it ;)
I'm 46 and have been programming for 39 years - 26 professionally ;)
Yes and what? Does it prove that you are programming with the good practices and methodology? Using the good designs?
Whether you think it is good practice or not is completely subjective. I've personally found it to be a terrible way to work, and have observed others doing it - being very unproductive