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
Top comments (10)
I think it's really efficient, and something that I would use when teaching CS. It's tough at first, because it can make us vulnerable and you have to be accountable to another human. Once you get past the initial hiccups, though, what a cool way to work.
It's not about mentoring, but I always come away from a pair programming session having learned a ton of new stuff. Interacting with others who are awesome at what they do is helpful.
Done it a lot at uni, but not after, sadly.
I noticed some pairings went great for me and some... not so much.
I tend to be a creative but chaotic, the right partner made the difference between "hey don't you mean
<rather than>?" and "You broke it! Why can't we do it the simple [lower-quality] way?". In the first instance our AI beat all our classmates', in the second our 'robot' shot as far to the left as possible regardless of inputs.Based on those experiences and discussion with others, I started to believe pairing men and women together works best.
Great post. I came across some pair program in sporadic episodes. It was basically on core components with a high impact on a project. The only rule is that the person who has and idea on how to do it has its hand on the keyboard. If both have an idea, they need to settle the argument beforehand.
I recently started a new job with a company that lives XP, and was super skeptical when it came to Pair Programming. I was coming from a few years of flying solo as a developer, so having another person with a different way of thinking about problems and differing opinions seemed like it would be more of a hassle. Boy was I wrong! It was definitely an adjustment, but now that I have been living pair programming for the last few months, its hard to imagine ever going back to the old way of doing things. I have learned so much from the devs on my team, and feel so much more effective and productive at the end of the day.
I'm a pair programming expert and a big fan of both pairing and solo-ing.
It is totally true that pair programming is a skill to be learned through practice. Once learned, it can be amazing, but, if a pair isn't set up correctly or if the power dynamic is off or if someone is being a jerk (which definitely happens) pairing can be a miserable experience.
Solo-ing is great because it's a great way to build confidence in oneself which is so important, especially for people in tech who are under-represented. If there is something you are trying to learn or research, solo-ing allows you to do at your own pace.
Do I have a favorite? I personally prefer pairing, but I like solo-ing too!
Pairing is grear for working ideas out with others in real time. I am glad I was exposed to it very early in my career because some people go through decades never trying it or feeling intimated by it. However I personally wouldn't say it's gaining popularity.
That is a nice article with plenty of details. But I would like to hear from the author and other people more about the manager's point of view, regarding pair programming. I am currently working in a software company where projects are handled by only one person. It would take a lot of effort to bring a colleague into the middle of my project and the second, more powerful, in pair programming would mean that instead of one person, two persons should be paid. Please enlight me if I am wrong.
it's very difficult at first time as you said but I think it would be nice and will bring well-structured code.
I've done pair programming, not all the time though, ever since I started in 1982. Don't really enjoy it, but it depends on who you're working with.
I love it (most of the time)! It's great getting other viewpoints while you're working.