Most software engineers are aware of the fact that pair programming can have some huge advantages. It’s one of the most efficient ways to share knowledge, it gives you an almost instant feedback loop, and it results in higher quality, less error-prone code.
Pair programming can be draining though. Being in a constant conversation with a colleague and having a continuous flow of ideas and feedback can be extremely tiring and might result in a severe headache at the end of your working day.
But it doesn’t have to be this way. There are some easy ways to improve the quality of your pair programming sessions which will help to make it – in addition to being super useful – a lot of fun. That’s why we have collected 10 tips to help you improve your pair programming sessions to make them digestible.
The two roles while pair programming
Pair programming helps you with having focus and being productive, but this is exhausting after a while. Don’t forget to take breaks once in a while. This can be every two times you switch role or using a set timeframe, for example. This will help you with regaining your focus after the break.
For some jobs (such as brainless, code monkey jobs), it doesn’t make sense to have two developers work on them. If you know up front that you won’t be able to give each other valuable feedback that makes it worth doing pair programming, it’s better to not even do it. If you identify this during a pair programming session, it’s time to split up and get back together after the code monkey job is over.
While doing pair programming, it’s essential to be open and willing to hear feedback and your partner’s opinions. If you’re going to do your own thing and you’re not open to what the other person has to say, it does not make sense to start pairing up. If you have people in your team that are not open for feedback, you might have more significant issues though, and this is definitely something to work on.
Only giving negative feedback will make it frustrating for the other person and will give them the feeling one of the two is superior to the other. Even if the other person is much more junior than you are, you can always learn something from that person. If this happens or if the person does something in the same way as you would do it, give some praise. It will improve morale and will also help the other person confirm that they are on the right track.
When doing “in person” pair programming, when sitting next to each other, make sure all other devices are turned off or closed that could distract you. Having another screen open will surely distract you when a notification comes in.
When working remotely, this becomes a lot harder though. Since the navigator is the only person seeing their screen, it’s extremely easy to quickly check something else and lose the train of thought. In this case, some practical tips could be:
Not everyone enjoys it when you’re sitting too close. Take care to not impose upon someone else’s personal space and avoid touching the screen and input devices of the driver. You can always ask to take over for a minute to show something, but taking the lead without asking is rude.
When you ask questions to the other person, it feels a lot more like there is mutual respect and that you value the opinions of your partner. You can turn almost all feedback into a question which will start healthy discussions and help voice both your opinions and reasoning. You could, for example, ask “Wouldn’t this be better?” or “Would that be an idea?”.
If you’re both not sure what the best action plan is, it’s time to do small experiments. Since there are two of you, you’ll be able to see the advantages and disadvantages of a particular implementation way faster, and it is thus not that costly to do an experiment which might be thrown away. If you do so, try not to take too much time to decide to keep the experiment or to go in another direction.
Don’t always pair up with people of your level or with people of an entirely different level. You can learn many things from everyone in your team (or even outside your team), so the best way to keep learning during those sessions is by switching up partners occasionally. It will also spread the insights you gained during a session to others.
It does not make sense to disturb your partner for small typos or easily spottable syntax errors (which are mostly already pointed out by your editor or IDE) because the chances are the driver will spot and fix it. It can help to give the driver a second or two to spot the error themselves before breaking their flow. This gives them the time to jump in there without losing their train of thought. Constant interruptions will definitely work counterproductively.
These tips will surely help you improve the quality of the pair programming sessions themselves and will also make you leave them with a good feeling instead of a headache. If you have more tips, feel free to mention them in the comments!
Madewithlove engineers often join the developer teams of our clients. We work closely together with them and use pair programming sessions when needed. Our developers have the necessary skills to be the technical and strategic voice in the way your teams are running. Check our service pages to find out how our technical consulting can improve and guide your product and team.