Pair programming is a bit like the buddy cop movies you’ve seen out there. You have two programmers working at the same workstation trying to complete a particular feature or get some tests to pass. Unlike the buddy cop movies, bad pair programming techniques can lead to frustrating scenarios. Whether you’re pairing with a remote developer or someone from the office, there are a few basic guidelines to follow to ensure that the pairing session goes smoothly.
1. Put your heads together(not literally, unless you want to)
If you don’t agree about how to go about completing a task before you start pairing, you’ll only create stress as you code. The best way to introduce your ideas is to first employ some soft skills. Clear the air by talking about anything that may be troubling you so that your fellow programmer doesn’t think that you’re grimacing at his code when you’re really just pissed about something else. The introductions can be as formal or as informal as needed, just as long as both of you can get on the same page mentally. Once you’ve done that, it will be easier to express ideas.
2. Set up a plan of attack
The productivity parlance “eat that frog” refers to doing your worst(most difficult) task first. When you’re pair programming, you’re probably better off doing the opposite. When I’ve pair programmed, I’ve found that the most exhaustive bit of the task of pair programming was in having to solve difficult problems. The patience and communication involved in working together can be draining. If this is your first time pair programming together, it will be much better to work on simpler tasks to grow accustomed to working with your pair.
Break down the task into smaller components and proceed from there. However, if you feel that the both of you are pairing rockstars, it may be beneficial to tackle difficult problems early on when you still have the energy to take them on.
3. What’s driving and navigating?
Aside from deciding what you’re going to be working on, you have to figure out how you’re going to work together. In pair programming, the roles of the pairs are divided into a driving and navigating role. Theoretically, the driver is supposed to be the adventurous road tripper who isn’t really sure about the layout of the land and loves asking for directions. The navigator is supposed to be equally unsure, but the access to information should allow her to help the driver.
Why is this theoretical? Well, depending on the coder, the driver could be someone who starts typing code without communicating. That leaves the navigator with nothing to do but check social media. That’s the worst case scenario of a pair programming session, but it doesn’t have to end up this way if the driving and navigating roles are properly defined.
Some of those new to pair programming may think of the driving role in the way most people think of driving: full control. Your job is to clearly communicate what driving and navigating means to both of you. Should the driver explain what they’re about to write before they write it? Or can they go ahead and write code, then talk about what they wrote afterwards? How much input should the navigator have in writing code? Is the driver mostly a stenographer who receives input from the navigator?
These questions don’t have to be answered. The point is to remind yourselves that the driving role isn’t a one woman/man show. Depending on the nature of the problem, the driver’s role can change. What is most important is that there is constant communication. An effective driver is someone who talks about the problem and possible solution out loud so that the navigator can chime in. A skilled navigator could even optimize a certain solution or refactor the driver’s code on the fly.
The navigator shouldn’t be demanding, however. Suggestions would be received much better if posed in a question. Syntax errors and typos can be pointed out at the last possible moment to give the driver space to breathe. In my pairing sessions, we had fun with typos and syntax errors, turning them into small jokes to lighten up the mood. At the end of the day, the driver may already feels a lot of pressure to write good code in front of their colleague. If the navigator is demanding, the driver’s worst fears may be realized, leading to an unproductive session.
4. Who’s driving and who’s navigating?
Once the roles have been defined, you can then decide how to best split up the task. There really isn’t a bad way to split up tasks. There are formal definitions like ping pong-ing where roles are switched upon completion of a specific task(it’s technically not a drive-navigator style). For example, the driver writes a test for a module and afterwards the roles switch. The new driver tries to make that test pass.
It doesn’t matter how frequently you switch as long as you switch. Switching roles is one of the biggest advantages of pair programming because, in a way, it reduces the pressure of sitting alone for hours hunched over your keyboard trying to solve a problem.
One great way to trigger role switches, if the nature of the task doesn’t provide obvious switch cues, is to set a timer. Every thirty minutes could trigger a switch. Be sure to take breaks in between as well to get some time to yourself.
5. Who gets the credit?
Thanks to git, there’s no need to fight over whose name shows up in the repo. When you create a commit, add a
Co-authored-by: name trailer under the commit message. To find out how to do that, check out this GitHub help page.
So, you’ve made your last commit for the day. Should you just end the session with a perfunctory good job? While that may seem like the nice thing to do, it really isn’t. If something didn’t go as you expected, it’s better to voice those concerns to allow the pair to fix those problems. The way to introduce those concerns is to first talk about what when well. Then, you can talk about what you can improve on individually or as a pair. Afterwards, you can mention specific issues you may have had with the pair.
If the feedback is given in the spirit of desiring excellence, then it will more than likely be taken in stride. The pair would at least respect you for you honesty even if they may disagree with you.
Hopefully, these steps have given you a blueprint about how to go about pair programming effectively. Pair programming can be a lot of fun if you do it right. You can learn a lot about the person next to you as you hunker down to solve problems. Don’t be surprised if you start sharing a few anecdotes or if a variable name triggers a discussion. Laying down guidelines may seem dull, but once you’ve set up a parameter, you’re free to play knowing that you’re both on the same page. Many site the disadvantages of pair programming, but there’s no doubt that, if done right, pair programming makes staring at code a whole lot more fun.