That moment when two developers are sitting across from each other, each staring into their own screen but working together to solve the same problem. That’s pair programming, and although it can sound strange at first, it’s an approach that has become more common in the world of software development over the last decade or so, with many developers swearing by its benefits. But how do you tell which type of pair programming to use, and when? Let’s take a look at some of the most common types of pair programming and see how they work!
In driver-navigator pairs, one programmer drives for a few minutes at a time while the other navigates. This is often done in coffee shops or open-space offices so programmers don't have to wait for others to arrive at their desks. There are also different styles of driving. For example, you can drive by telling your navigator exactly what code to write next, or you can drive by saying what you'll be doing next - then letting your navigator decide how best to accomplish that goal. The former style ensures that things get done quickly and accurately; but it takes practice to do well.
This is probably what most people think of when they hear pair programming. The unstructured style, as its name implies, doesn’t prescribe much other than two people sitting down and writing code. This has many upsides: you can try out new techniques or languages to see how they work (and who better to learn from than your experienced coworker?), and there are no set rules for collaboration, meaning you can work at whatever pace suits you best. Unstructured pair-programming sessions are great for getting a lot done in a short period of time—you have twice as many brains on hand after all—but may not be great if you want someone else looking over your shoulder telling you what to do every step of the way.
This type of pairing usually consists in one developer who is designated as driver or navigator for a given time slot. That person will drive most of the interaction with writing code, while his or her pair will provide feedback about design decisions, ask questions about problem solving and check whether all requirements are met. This approach tends to be more efficient when you’re dealing with very specific tasks that require deep knowledge about a given domain or technology. It’s also good for beginners who may need guidance in some areas before being able to fully take charge.
When pair programming, ping pong pairing means you and your partner trade off roles: One person writes code, while their partner reviews it. The driving and navigator roles will switch back and forth as well; however, because one programmer will know more about what to do than his or her partner, there is usually a bit of lead time to get things set up for that person to drive before they begin typing again. The end result is that both partners benefit from working on one task together without switching back and forth between tasks. It also creates a dynamic where neither partner can dominate or take control over another’s work. Although there are many different types of pairing arrangements, ping pong pairing is a great way to share responsibilities evenly.
The backseat navigator knows what he wants to do, but doesn’t always know how to get there. In practice, you may find yourself dealing with a backseat navigator in two ways: You both can write code, or you might be pairing with a developer who's looking over your shoulder and telling you what to type. If it's one-on-one pairing and you're a veteran programmer, a backseat navigator can actually help you solve problems.
This style of pairing is used for two developers with different skill sets, such as a junior and senior developer. The lead is responsible for doing most of coding and is usually paired with someone who needs guidance, has specific knowledge that can be used, or just wants to see more. The junior dev focuses on improving their skills by asking questions and learning from what’s happening around them. This pairing is ideal when one person knows more than another about something like a new library or framework. Because both programmers are focused on writing code, there isn’t much time for chit-chat; however if either dev has questions about how something works they can ask before committing code.
With distributed pairing, pairs are separated in different locations. For example, there may be two people in India and two in Canada; or one person in Los Angeles and another in New York. Pairing is carried out over computer networks rather than face-to-face. Distributed pairing can be used when individuals are located far apart, so no one is forced to travel long distances to meet face-to-face with their partner for pair programming sessions. One major benefit of distributed pairing is that it's convenient for all parties involved. It gives you access to better developers by providing an opportunity to work with specialists who live far away but have specific skill sets that complement your own skillset.
There are many different styles of pair programming. It’s important to understand these differences so you can find what works best for your team. The most important thing is that you choose a method that makes sense for your specific team, then dive in and see
Create your free account and start collaborating right away with your team on all your apps. Should you have any questions about our offers, be sure to contact us.
