Surviving software development with pair programming

Ivan Santos
Nomads on Rails
Published in
3 min readAug 31, 2015

All the questions relative to pair programming start with a necessity of something. Mine happened when I first started working remotely. I had no idea that as a remote worker, coding communication would be a big issue. The way that I needed to interact with the coworkers and the nature of being part of a project team changed a lot.

The necessity of self and project improvement created a process called by “Pair programming”, which means the situation where two people team up on a project and divide the work into distinct roles: the navigator and the driver.

Following the basic concept, the navigator is in charge of creating the concept and directions to the approach for solving a software problem. The navigator acts a reviewer, observing and providing a more strategic and architectural approach. The driver controls the keyboard and focuses on the immediate task of coding. He is responsible for translating the navigator’s approach into code. In a period of time the roles are swapped over the course of the project, providing the opportunity to be in both of the roles. After defining who is the driver and who is the navigator is necessary a problem definition. Something that you can solve in a few minutes.

By the time that I started doing that, I asked myself what’s the real purpose of this process. I realize that pair programming is not just about code improvement and bug finding, but it’s also a good way to improve your communications and cognition skills.

In the traditional way, students are taught to follow instructions and sometimes present ideas. In pair programming, they have to create and absorb instructions to each other, with requires a better understanding of all the use cases. Being in a cycle of pair programming is something that requires attitude. You need to be sure that it’s going to be slower than solo programming, and sometimes you are going to have a feeling of wasting time.

Unexpectedly, you end up saving your time later with a better cycle of catching bugs and an accurate implementation.

Having a good attitude can turn pairing programming into a fun activity where you can always learn something new, such as a new approach to coding, a new pattern or just how your partner usually writes tests. Interacting with partners can be frustrating sometimes because usually going to be surrounded by the internet and issues, we end up having a lot of distractions. Working remotely for me is one of the biggest problems, but it could be worse if I didn’t have this opportunity of being in touch with someone trying to solve a problem.

When you start doing pair programming you may get out of control and not stop coding for hours. Periodic stops are healthy and can help you to get rid of stress. It may be good if you take 5 or 10 minutes every 1 hour of coding.

Experimental evidence has been helping the developers to become better professionals. Pair programming could be really efective in your environment or sometimes just don’t work very well as you expect. One aspect needs to be considered. If you’re not enjoying pair programming, that means you need to reconsider the way that you’re doing it. Trying to understand what you are getting in benefit of using that technic is one of the best ways.

--

--

Ivan Santos
Nomads on Rails

@pragmaticivan, views expressed on this blog are solely mine, not those of present or past employers.