DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

Cover image for To Pair or Not to Pair: Introduction
alaje
alaje

Posted on • Updated on

To Pair or Not to Pair: Introduction

Pair programming, aka pairing, is more than what you're probably thinking it is even if you have a good grasp on the words pair and programming.
When we have two people working together on the same computer... on the same code, we have a setup for pair programming. Due to reasons, these individuals might find themselves at different locations, when this is so, it is a popular move to use video conferencing tools to accomplish this process.
Now, just putting two people together, in front of a machine displaying some code is not pair programming. With pair programming, you find a situation where two people constantly communicate with each other about the code, find each other's errors and try to bring out the best possible code to write that accomplishes their sought after goal. These programmers are expected to work as a team.

So things might seem weird at this point, like how does a person actually share a machine with you?


How does this actually work ?

There are two roles, one for each person, obviously. We have the navigator and the driver.

What does the driver do?
Just like how a driver interacts with a car, the driver in this case works directly with the machine to actually type in the code.

What does the navigator do?
The navigator exists to give pointers, answer questions from the driver, ask their own questions about the code being written, and intensively read the code as it is typed so that mistakes are noted fast. With a navigator, the driver not only has a pair of eyes on the code, but also another brain on it.


Both continuously communicate about the project and the best way to do it. The driver can explain -out loud- what is being typed, and the navigator can keep track of what has been done and what is suppose to come next.
There is no designated person for a role, and participants can and should switch roles as many times as they deem fit so that both programmers can learn from each other.
Some more common pairings might involve:
A junior programmer and a senior programmer, to allow an easier onboarding process by letting a person more familiar with the code base to serve as a navigator.
or
Developers of the same rank so that they can properly learn from each other.


Like every practice, pair programming can be adjusted to fit the company's workflow.


Learn more with my next post To Pair or Not to Pair: Benefits https://dev.to/ulimicreator/to-pair-or-not-to-pair-benefits-7e

Top comments (0)

Timeless DEV post...

How to write a kickass README

Arguably the single most important piece of documentation for any open source project is the README. A good README not only informs people what the project does and who it is for but also how they use and contribute to it.

If you write a README without sufficient explanation of what your project does or how people can use it then it pretty much defeats the purpose of being open source as other developers are less likely to engage with or contribute towards it.