Pair programming is an interesting practice that's picking up in popularity. For some shops, that's the only way they work. Two developers, one screen, one chunk of code at a time. Usually one developer writes the code while the other observes the code being written. The goal of it is to produce better code and more maintainable code because you have to skilled developers working on a task together with specific roles.

It's a part of the XP (extreme programming) methodology which tries to drive development faster and with a higher quality. You'll see it used in agile environments all the time and a lot of developers really like it. Instead of struggling through problems on your own, you always have another set of eyes looking at the same thing a bit differently. Here are a few unique things about how pair programming works.

It focuses on the code as it's being written

In a lot cases, you will have someone who is observing and someone who is typing. As you both progress through the implementation for your task, one of you will catch something the other misses. For example, you might forget to initialize an array while you're typing and the other developer catches it. Or the other developer might ask why you are writing the code a certain way.

You take care of the code as you write it because you literally have someone watching you. There's no more room for lazy code and the best part is that it keeps your code maintainable in the future. You don't need a specific developer to explain how everything works because you have readable code. It also helps bring best practices to the forefront of everything you write. Having an extra set of eyes while you're thinking through a problem can help you write better code.

It's not about mentorship or teaching

This takes some developers a while to grasp. Both developers are on an equal level and they both have valid opinions that need to be justified. You aren't in a mentoring situation when you are doing pair programming. You are two developers helping each other write the best code possible for this task.

Over the course of working together, you will definitely learn new things from your partner. Just keep in mind that isn't the primary goal. The whole point of pair programming is to keep each other focused on the task and to brainstorm when you run into issues. It's more about getting the right code written to fix the problem in a way that is inline with the team's practices. Any mentoring or teaching that comes out of it is a nice side effect, but it's not the main focus.

It takes time to develop the right skills and mindset for pair programming

Working with another developer on code isn't the way most shops work. The majority of places will have you work on tasks alone and you can ask for help if you get stuck. Switching to pair programming is a drastic change and it will take developers a while to gain the new skills and mindset they need to work in pairs. Nothing happens overnight and there will be some rough times, but once you get through it you reap all those benefits.

Some organizations take their time to create rules for how developers should work in pairs. That where the different roles in pair programming, like the navigator-driver roles, come from. It takes some time to get the rules in place and it's important the developers are providing some input. After those rules are in place, you'll notice that your pairing sessions go smoother.

The benefits are great when your team gets it down

When you have the pair programming process down, it starts to build momentum. The more developers work in pairs, the better the code gets especially if you use it with something like test driven development. Writing tests together makes sure that both developers understand the task at hand which means knowledge is being shared. This is highly overlooked in many teams. Cross-training is a subtle benefit you get from pair programming that makes a tremendous difference.

It really takes some time to get used to someone watching you code and having that back and forth over the best implementation. The majority of developers are used to writing their code alone. I know I was. In the long run, you do end up learning some new ways to implement code just because you've been exposed to another developer's perspective in real-time with valid justifications.

To be honest, I didn't like pair programming at first. I thought it was weird and slow and that code reviews and pull requests were good enough. It's grown on me some and the benefits have been great, but I still like coding alone and going over it later. What do you think? Are you all in for pair programming or do you prefer to code alone?

Hey! You should follow me on Twitter because reasons: https://twitter.com/FlippedCoding