Pair Programming: The how and why?
As a boss it’s easy to look at pair programming and think, “What a waste! Why on earth would I have two people working on something when I can have them work on separate projects!”. I get it. If I was looking at it for the first time that might be my first impression as well. At first glance, you’d think that it doesn’t seem practical, but theres plenty of evidence to show that there’s less bugs when people work together and your programmers are gonna be a little happier.
What is it? How does it work?
So just what is pair programming? Well it’s essentially two people working together at one problem with one member taking the role of driver and the other as the role of observer. So what are these roles? Well, the driver is the one who essentially does the coding. They’re the one with keyboard control and typing everything out. Don’t worry, they’re not doing all the work though, the observer is the one who thinks out loud a bit more, by directing the driver through their code. They’re also the one doing a bit more big picture thinking. While the driver is writing out the code, they’re thinking of potential road-blocks that are coming up and how they can avoid them early by steering the driver in another direction.
Pros
Less Bugs
The dreaded bug, the one line of code that can sometimes take you ages to track down. It can be as simple as a typo or a missing comma and you might not even notice it until the very end of your task. By using pair programming we can often spot them as they happen just by having that other set of eyes. Plus sometimes we need someone to tell us to stop at certain points just to check if everything up to date is working.
Growth
Whether it’s two pros pair programming together, a pro and a novice, or two novices, pair programming provides an incredible learning opportunity. The best example of growth in my opinion is having a pro and a novice. By pairing the two up you allow the novice to see how the pro works. They can share valuable insights into coding that might have taken them years to develop and tricks that they’ve found along the way. By sharing these with a novice you can only increase the novices productivity, and sometimes you can even teach the pro a new trick. With two pros, it’s very much the same thing with both being able to learn from each other although there isn’t as much to learn when both have years of experience. Two novices will have the least amount of productivity as they will be the slowest, but by overcoming obstacles together they can learn valuable skills about teamwork and still increase their productivity.
Focus
Whether we’re working at home or at the office, it’s easy to get distracted. It might be by checking our phones and scrolling through social media or by conversations with someone working nearby. When you’re pair programming. it’s a lot easier to stay on the task at hand. When you have someone directly relying on you, you can’t exactly just stop talking or typing when someone is in constant contact and if you stop you’ll have someone asking you why.
Cons
Compatibility
As we all know, not everyone gets along. No matter how hard we try there’s always going to be someone that we just don’t work well with. If you’re pair programming together and there’s a difference of opinions on which direction to go in, then it can very quickly lead to a stand off where productivity becomes stagnant. It’s important to be able to recognize compatibility as both the employer and the employee. If you can recognize this early on then you can hopefully steer members into different groups.
Knowing when you’re out of your league
As a developer it’s easy to get stuck on a problem and try and work on it through a dozen different possible solutions. This can even happens in teams. But it’s important to be able to recognize that if we’ve been working at a problem for a while and haven’t gotten anywhere, then it might be time to call in the big guns. As a junior developer it can be intimidating to admit to your co-worker that you’re stuck or lost and they might be having the same thought. You need to be able to admit that you might be in over your head. Sometimes by bringing in the pro they can get you through it in a matter of minutes, ‘cause get what? They used to be you and they probably had to deal with a very similar issue and they happened to know exactly how to get around it.
The don’ts of pair programming
Not switching roles
If you want to be equipped to be a well rounded developer then you need to be comfortable as both the driver and the observer. You also can’t let yourself get stuck always being one or the other. If you do that then there’s a good chance that you’ll be found lacking some skill when you do eventually switch roles.
Staying at it for too long
It can start out great with few distractions and being able to really power through your work, but after a while fatigue sets in. You have to be able to stop every now and then to take a break. If you’re not careful and you don’t take those breaks, then you’re going to be more likely to make mistakes and have bugs in your code.
To end it off I myself have really enjoyed pair programming. It’s been a great resource for seeing things from someone else’s perspective. It’s allowed me to see solutions I never would of thought of and really helped me grow as a developer. It’s a great resource for beginners and pros alike and I definitely encourage you to give it a go.
Footnotes
Here’s some other references for you to that I’ve enjoyed reading for this post that might be a good read for you as well
