“Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently.” - Wikipedia
It is important to understand HOW and WHEN to do pair programming. If you are doing pair programming, but it is not performing well, you are doing it wrong.
Pairs typically consider better design and quality, they are faster to find the solution and solve problems than programmers working alone, and pair programming dramatically improves knowledge sharing on the team.
- Fewer mistakes.
- Better design and decisions.
- Faster to find problems and solve them.
- Harder to procrastinate.
- An effective way to share knowledge.
- Best practices are always shared.
- Better onboarding experience.
The navigator is constantly reviewing every line of code. While the navigator doesn’t have the control, he/she has more capacity and good focus to catch errors and mistakes in the code. It works better than code reviewing the pull request because the navigator is involved and has more context.
Having two heads means better design decisions. Also, in the long run, the knowledge is shared within the team, which means your team has more power and experience to solve problems. Novice will learn how an expert finds the problem and implements a solution.
As much as doing it right will give you many benefits, not doing it correctly has some side effects on your team.
It will end up being very inefficient and unproductive way of working that only increases man-hours comparing to working individually.
The navigator will get distracted more often and is less productive. In the long run, it will turn the environment/team-space into a counterproductive space for the navigator and he/she will lose his/her performance.
The driver has control and writes code and navigator reviews and gives suggestions. They switch role and have different responsibilities.
Some of the rules are specific to the level of expertise on the task. (expert-novice, expert-expert, or novice-novice.)
Assume two relative levels of expertise on the task. The expert has more knowledge about the task/project comparing to the novice.
Note: Remember the usage of these titles is not related with the job title or anything like that. It is relevant to one another and the task.
Stick to the basics: Pair programming often confused with helping, collaboration and teamwork. It is easy to do it wrong (ineffective) by not following the basic rules. Please stick to the basic rules and implement it correctly. Drop your questions if you don't understand why.