Cover Image: Woman Wearing Red and Black Checkered Blouse Using Macbook by Christina Morillo
I spend a considerable amount of my time pair programming.
I'd say it is how I spend most of my time programming at work.
That has led me to develop some guidelines on the practice of pairing (which I will happily share), but first some background:
Pair programming originated as part of the Extreme Programming movement.
The idea can be boiled down to code review with context. Code review is a common practice in which a programmer, besides the author reviews a suggested change and offers critique or advice.
When you're pair programming, each programmer is essentially providing code review for the other, with the added benefit of context.
Think of it as real-time, continuous code review.
The real-time nature of pair programming is beneficial because a lack of context frequently hampers code review; the reviewer can't always infer why the author followed one train of thought over the alternatives. This lack of context can result in a lower quality of code review. It would be better for the sake of the code if the insight could be supplied while fingers are on the keyboard, rather than after a change has been suggested.
For this reason, and because there are other benefits to collaboration (think about mutualism in biology), it can be advantageous to adopt the practice of writing code as a pair (or in the case of mob programming, a group).
In pair programming, development becomes less of an act of singular creation and more a synthesis of ideas. That is ideas which have already been vetted by at least two minds, rather than one mind.
In my opinion, diversity usually results in better decisions. The same is true of programming. Two people writing code together will approach problems from different perspectives and fill in each other's blind spots.
Ultimately, I find that pair programming results in increased productivity and a higher quality of output than the alternative of splitting engineers onto their own tasks. This idea can be a hard sell to management, but I'm not the only one who feels this way; some companies do pair programming exclusively.
That being said, it is possible to adopt pair programming and not reap the rewards that many people associate with the practice. There are plenty of patterns that should be avoided, and many good patterns that require mindfulness to practice effectively.
The following list is by no means complete, but it includes some simple tips that I've found are incredibly effective at making pair programming more productive. While writing this, I'm assuming that you're pair programming in-person, but the same guidelines apply even if you're pairing over a shared terminal or Tuple.
1. Respect one another
Displaying mutual respect is the most crucial part of this entire practice.
At the very least, you need to respect one another as colleagues to work as a team. That is the bare minimum, and it is unfortunate that it even merits writing about, but I've seen plenty of developers be down-right rude while pair programming.
If you can't respect your colleagues while writing code, it is imperative that you take a step back from the code and revisit your understanding of empathy.
For people that find this particularly hard, I recommend reading How to Win Friends and Influence People. At a minimum, you will learn to make other people feel valued, and if you're lucky, you'll build some empathy along the way.
When in doubt, remember the sage advice of Bill S. Preston, Esq.
Be excellent to each other.
2. Be mindful of your communication
Good communication, like good code, can be challenging to quantify. However, much like good code, you also know it when you see it.
Mindful communication has less to do with learning to speak well, and more to do with learning to process what other people are saying and deliver your own thoughts with the best intentions.
To a degree, communicating well is an extension of respecting your colleagues. Give their words the attention that they deserve and be intentional with how you phrase your feedback.
Being mindful of your communication also includes using inclusive language; aside from the obvious (do your best not to offend people), you should also strive to avoid using phrases or acronyms that your pairing mate might not know. No one wants to be made to feel ignorant. If you're unintentionally making someone feel ignorant, they might feel disinclined to contribute their thoughts, and you've eliminated an extremely valuable piece of the pairing process.
If you're unsure how your language affects others, play it safe. Generally, I try to explain any unique terms or jargon I might use while pair programming.
3. Set expectations
Observing those first two guidelines can be harder than you think. It's a good idea to communicate about those things if you aren't extremely comfortable with your pairing partner.
I find that it's easier to set the tone with a few expectations than to try and correct after doing something that might frustrate your partner.
By setting expectations, I mean explaining that you are there to help and letting your partner know it's totally fine to ask any question (no matter how embarrassing) and that they should share their thoughts freely without fear of useless criticism. That isn't to say you shouldn't try to help your partner when they are incorrect or have incomplete information, but you need to be constructive when you offer feedback on their suggestions. This applies to both partners regardless of seniority.
Another good idea is to set ground rules about personal space and hardware. I've seen quite a few frustrated pairs reach over their partner and grab a keyboard (that's rude and can be offensive). Instead, think about how your body language could be interpreted and always ask if you can use another person's keyboard before reaching for control.
It may seem a little awkward to go over this kind of thing with your colleague, but I think most people appreciate the thoughtfulness of setting expectations, and it is a great way to set a pair programming session up for success.
4. Let the junior drive most of the time
Once you're writing code together, it can be super tempting for the more senior of the pair to assume most of the control by typing. I don't like that pattern because all-too-often, while at the helm, the senior will forget to articulate precisely what they are doing.
Things that seem mundane and routine to an experienced developer might be non-obvious and even confusing for a less experienced developer. So generally, it's a good idea to explain why each step was completed in the development process.
I feel that there is a straightforward way to avoid this problem of failing to articulate: put the least experienced programmer in front of the keyboard. In this arrangement, the senior partner can't contribute code without explanation because their only vehicle for expressing ideas is communicating it to the person at the keyboard.
Therefore, I believe it is ideal that in the pair programming situation, the more junior partner is the default driver.
That is not to say that the more senior developer shouldn't touch the keyboard. In fact, I've had colleagues disagree with me on this point fairly frequently because a more junior developer can learn a lot just by watching the workflow of a more experienced software engineer.
So, it's probably best to keep this balanced, but I tend to think that the less experienced hands should be on the keyboard.
5. Keep talking
It is totally fine to leave air in a conversation, especially when the participants are thinking hard about difficult problems. However, it is vital in pair programming that the participants share their thought-process.
That isn't to say you need to vocalize every thought that pops into your head (I'm guilty of doing that), but you should try to articulate the path your mind is traveling down. Doing so allows your partner to catch a flawed thought process early, and it has the added benefit of exposing each of you to new ways of perceiving problems.
I feel that it's essential to continually look for ways to explain what you're currently thinking (and why) so that you can benefit from the thoughts of your partner. This also allows your partner to learn from you; your thought patterns, how you write code, your thoughts on the development process and your mental models can be useful for other programmers, so it's good to share them during the pair programming process.
One of the easiest ways to waist pair programming time is to sit silently while one of the two partners works.
Keeping a conversation going also has the benefit of allowing each partner to communicate when they need a break, when they are feeling frustrated, or when they think it's time to move on to a new problem. If you make it easy for your partner to talk to you, you will find it easier to practice mindful communication and respect one another.
6. Don't dictate code
At some point in a pair programming session, someone will inevitably dictate code. This is what I call it when programmers start listing off specific characters to type.
It's tough to avoid this problem, mostly due to varying levels of comfort with a programming language or a paradigm, but I have found that it is almost always more beneficial to speak in terms of what you're trying to accomplish.
Instead of asking your pair to type, "if paren x equal true paren," it makes more sense to tell them that you think it's necessary to check some value with a conditional. This helps both of you to say what you mean, and it doesn't leave one of the partners in the dark while hammering out characters.
When you're dictating code, you might as well be programming by yourself because your pair isn't going to be able to contribute much until they know where you're going. If you ask me, it's more like using your computer's voice dictation software than pair programming.
Again, this is very hard to avoid. Honestly, sometimes it is a good thing (for example, when one partner is unfamiliar with the syntax), but it shouldn't be your default method of communicating how the code should work.
As an exercise, I like to avoid getting any more specific than verbal pseudocode, which is a step above dictating code.
7. Find teachable moments
Totally straightforward! When you're working with a partner, look for opportunities to teach them your tricks and share knowledge. If you notice they aren't using the editor shortcuts you love, it's a great time to ask if they'd like to learn. If you notice that your partner isn't using great git hygiene, you can share your thoughts on using git.
A word of warning: be careful when looking for teachable moments, some people might not want to know every trick you like. It's best to space these out while you're working so that you don't accidentally annoy your colleague.
I'm hoping that these guidelines will help people embrace the practice of pair programming and knowledge sharing as a pattern. I've benefitted a lot from pairing with both senior and junior colleagues, but I've also seen plenty of bad examples of pair programming along the way.
Obviously, my opinions aren't perfect and these guidelines are flexible. Individuals are unique and the dynamics between them can be just as unique, but in my experience, this list is a good compass until you've developed your own rapport with a pairing partner.
One final thing, I generally write articles as notes to myself or at least as an effort to consolidate my thoughts on a subject, but I know that developers have very strong opinions on how we make software, so I'm hoping a few people will chime in with more pairing tips in the comments.
There's more...
I'm writing a lot of articles these days, I run a podcast, and I've started sending out a newsletter about all of the awesome stories I'm hearing.
You can also follow me on Twitter, where I make mediocre memes and talk about being a developer.
Top comments (10)
Never truly did pair programming, but I can imagine what it's like and what the benefits are ... I think code reviews are the best next thing, I'm doing those a lot - I also have the habit of always reviewing my own code before committing and even while writing code - that's sort of like doing pair programming with yourself :-)
I think pair programming, like TDD, is one of those things which almost everyone agrees on (regarding its usefulness), but which nevertheless relatively few people are practicing ... both PP and TDD just require a huge amount of discipline.
It can definitely be hard, but I think once you've seen Pair Programming done right, it is difficult to go back!
I believe you :-) and actually I think it's less of a hype and more of a realistic thing than TDD
Do you not find pair programming mentally exhausting? Programming can be tiring enough. I feel like pair programming just enhances that. Once in a while might be ok, but I wouldn't want to do it everyday or for very long.
Though I'm sure some people find it more enjoyable than others.
It totally can be. Like most things, it gets easier the more you do it. 🤠
Can pair programming be noisier? Thinking about the case of multiple peers working in the same room and how to handle it.
Sure, but I've found that open offices, in general, don't facilitate deep work well.
If you can't find a secluded place to pair program, try a coffee shop or something.
We use pair programming on one project. We change positions every 10-15 minutes. Productivity rapidly grow up.
That's a really good tactic, it ensures that both partners are involved.
This sounds awesome