If you say: “Oh yeah we do pairing all the time” — you are probably doing it wrong!

Pair Programming (also often referred to as “pairing”) is a great way of working that combines lots of good practices. If you do pairing right, you will get automatic code reviews, knowledge sharing, improving collaboration and team building in one.

What I often heard though is it not being really done or understood right. If you ask a person that writes code if they do Pair Programming, many would actually hesitate first to think about it and then say yes. What they often refer to is looking at code together with another person. I often heard people say that they do this by sharing their screen, then they show what they have done and code and the other person just listens. This is not really Pair Programming though. It might be a similar difference between someone walking to get from A to B and another, an athlete, doing a 500m sprint. Sure they both move between a distance but the way they do it has major differences.

So how does pairing look like done right? There is an article that explains in full detail on how you could do pairing. The main difference is that you should use a structured approach on how you pair so pairing becomes about critical thinking together and problem solving rather than one person being active and talking all the time and the other becoming passive. If you do it right you switch between strategic thinking and executional thinking multiple times between the pairs and discuss about clean and readable code and how to arrive there.

Strategic thinking is thinking about how do you solve a problem. It is coming up with a plan on how to implement a feature and how the design or concept of the solution would look like (e.g. drawing something on paper how it could be solved). This requires thinking about design patterns, software architectures, components, workflows or processes.
Executional thinking is about taking that plan and pouring it into code. Using clean code and best practices to find a nice way of implementing the plan. This requires thinking about design patterns and how they can be implemented in the language you are programming in, interfaces, functional programming, API definitions, packages, modules, tests, test strategies.

So next time you prepare for an interview or are looking into ways how to improve the way you work, think about researching a bit on Pair Programming and what it should do for you, before just saying: “Oh yeah we do pairing all the time”.