I’ve been in a pair programming environment for about a year now (as of this post) and I have witnessed a different array of reactions from developers about pair programming. Some developers dislike or even hate pairing, while others like it. Among those who dislike pair programming, I have noticed that they have similar reasons for why they dislike pair programming.
So, this leads to the topic of this post, which is how to tell if pair programming is going to work for you. This is based on my own personal experience and is in no way a definitive guide to determine if pair programming is for you. This post should give you a better idea in what to expect from pair programming and what possible issues you will encounter.
You Dislike Pairing
Let’s get this one out of the way as obvious as it may be. You gave pair programming a sincere chance and you end up not liking it. Nothing says it more strongly than how you feel about something after you did give it a sincere chance. A sincere chance for this case is trying out pairing for a good duration like at least half a year.
Do You Code Quietly or Speak out Loud?
Pair programming requires engagement from both developers. One of the best ways to keep engagement up is for there to be constant discussions. This means pairing should never be the case where one developer is writing code silently and the other developer is just observing and guessing what the other is trying to do. Before writing any code, both developers need to communicate and agree on what needs to be coded.
So, if you find communicating your ideas before any code is written to be difficult for you then pair programming might not be for you.
Are You Empathic?
Pair programming requires a developer to do something they rarely do when they write code and that is dealing with the feelings of others. If you are writing code by yourself, all you’re dealing with are emotionless being (code, syntax, computer, compilers, and etc you get the idea). However, when coding together with another developer now being brought into the mix are emotions (not just your own).
Dealing with code and machines is one thing, but it is another to deal with human beings. You need to be empathic to effectively deal with people. If you are pairing with someone with a different set of perspectives will you be able to understand where they are coming from? Can you put yourself in the other person’s shoes?
Do You Code First or Think?
Some developers think first and others think by code first. Considering the nature of pair programming you need to communicate (think) first for it to be the most effective. You might think, the idea is perfectly clear in your mind so what is wrong with coding it? Well, that’s because your partner is probably not a mind reader and would have no clue what you’re trying to do. Without discussing with your partner before writing any code, you’re eliminating the possibility for a better solution and will very likely not be on the same page.
You Think or Still Believe That Pairing Is Double the Cost
The common belief is that pair programming is going to cut productivity in half because two developers are working on one thing. However, if you give pair programming a sincere chance, you’ll realize that it doesn’t cut into productivity by as much as you think. Initially, it might be slow, but once your team finds a good rhythm, things will be going smoothly again.
If you have been doing pair programming for a while and you still believe pairing cuts productivity in half then it’s probably not for you.
Do You Get Along with Others?
If you answer with an immediate “yes” then maybe you need to give it a bit more thought to your answer. We’re not talking about the occasional chit-chat you might have with your coworkers when getting a cup of water or even when they ask you a question or two once in a while. We’re talking about roughly eight hours a day sitting next to your coworker working together and sharing the same computer screen. How does it make you feel thinking about that?
What about when you have a disagreement with someone in how to solve a problem? Do you always default to believing you are right?
How Do You Take Criticisms?
With the nature of pair programming, you’ll get constant immediate feedback from your partner. Feedback for the code you write to the solutions you have to a problem. Some of them will be positive, while others will be negative. I am sure you’ll be fine with positive feedback, but what about the negative ones? Remember, the one giving you these feedbacks is also sitting next to you for the whole day.
How Do You Learn?
We each learn differently through a combination of learning styles. I won’t be diving into learning styles in this post, but if you’re interested I have a post dedicated to learning styles. Whether pair programming works well for you or not will depend on how you learn. If you learn well by talking and listening then pair programming got you cover.
Do You Only Want to Drive?
When you’re pairing, do you only want to write code (drive)? When you’re in the navigator seat do you get bored and struggle to be engaged even when there are constant discussions? If you only want to write code, then pair programming doesn’t enforce that model. Ideally, you’ll be writing code at most half the time and spend the other half being the navigator.
I hope this post was helpful to you. If you found this post helpful, share it with others so they can benefit too.
What are your experiences with pair programming?
To stay in touch, follow me on Twitter, leave a comment, or send me an email at steven@brightdevelopers.com.