An Introduction to Pair Programming

Jun 18 · 4 min read
Photo by Geran de Klerk on Unsplash

This week I was working in pair programming and sometimes in the mob. But what is this whole concept of coding together? Isn’t it just a slightly better naming for: “Yes! Somebody else makes my job!”? Are we really more productive this way?

These were the questions that I had, when i first started with pair programming and working in the mob.

What is Pair Programming

Pair programming is the art of coding together in a really efficient and productive way. The concept of pair programming is pretty simple. Someone is coding while the other one is just saying the coder what to do.

The only way that such a way of working can work is by defining some rules.

In theory, this way of working should increase the creativity and more importantly the quality of the end result. Mostly, working in pairs is a little bit slower than working alone for simple and small tasks. In longterm, the quality improvements of the code will make up for the only slightly slower process of actually writing code. Also it allows us to skip an extra code review since 4 eyes already saw the code.

Pair Programming has two main roles. The first one is the driver which just codes as fast as he can. The second one, the navigator, is in my opinion the even more important role of these two. He tells the driver what and when to do something.

Don’t get me wrong, the driver also has to think about the code he is writing, but mainly the navigator decides what to do and is talking the most. The driver is also communicating what he thinks and writes to the navigator.

It is really important that the driver and the navigator have a good connection to each other so that they can communicate fast and clear with no room for wrong interpretation.

There are many rules for effective pair programming, but these are in my opinion the most important ones.

  1. Switch the roles frequently
  2. Take breaks regularly
  3. Switch off when it’s time to google
  4. Talk in positive terms
  5. Have the right tools

In general, you have to switch the roles about every 25 minutes. In these 25 minutes the team is actually writing code for 20 minutes. The other 5 minutes are preserved for checking mails, setup the project and some other smaller stuff. The reason why we have to change the roles this often and not just something like once a day is, because this way both of the members of the team really NEED to be active. If the changing intervals would be larger, you’re running on the risk of not being actively contributing to the code.

Pair programming is very mentally demanding because of all the communication and the need for a high concentration level. To regenerate your brain power from time to time you need to take regular breaks.

Plan to take breaks and take it into consideration when creating a timeplan. If you don’t do that, you’re taking the risk that you forget to take breaks the whole day… Believe me, that is easier to forget than you would first think.

In many cases, you need to research a lot about a topic. In these cases you can simply stop the timer for changing the roles since both team members are doing the same thing. When starting to code again, don’t forget to restart the timer. 😏

This point seems a little unrealistic, because you can’t always say something is good, when it’s clearly not. Its not about what you say to your partner, it’s how you say it. When you have a positive atmosphere in your team, it’s much easier to communicate clearly and a positive attitude can motivate the team for better performance and creativity.

Since pair programming requires a lots of communication, it is necessary to have a good way of communicating to each other. In the times of the pandemic, it’s mostly the easiest way just using something like Zoom, Slack or Teams. In combination with git, it should provide a pretty seamless coding and switching experience.

There are also some other options like CodeTogether, which is essentially a plugin that’s available for most IDEs like IntelliJ or Eclipse. With this solution you basically work from one desktop and don’t have to commit the changes every time to git. This has a good but also a bad side, so decide by your own what fits your needs the most.

An other thing necessary for pair programming is a good timer. For me, Horo Timer worked perfectly.


I think I learned a lot by doing some pair programming. I had a more creative ideaflow then when I was working alone. You can always learn new stuff from your partner, that’s what I like.

Sometimes I forgot to start the timer after a break or even forgot to take regular breaks at all. Next time I would try to remind myself more about the rules of pair programming, especially the ones with the regular switching and taking breaks.

Geek Culture

Proud to geek out. Follow to join our 1M monthly readers.