When you think of paired programming at first it may seem like a waste of time, or like the other person will just slow you down. I get it. I felt the same way when I first started out as a web dev student. Why would I work on something with another person when I could get through it more quickly on my own? After trying pair programming a few times, I learned that though it can go either way and may slow the pace a little, there can also be lots of benefits to pair programming when done correctly.
Since we are talking about paired programming, it is hard not to bring up the ENIC Women, considered to be the first programming team ever, who worked on the first programmable computer completed in 1945. As Jean Bartik said, “Betty Snyder and I, from the beginning, we’re a pair. And I believe that the best programs and designs are done by pairs, because you can criticize each other, and find each other’s errors, and use the best ideas.” Crazy to think that the first team that was writing code was doing it in pairs before they had any books or research to suggest it to them and they just found it was the best way to accomplish their goals.
My experience with paired programming has been both as a student and on working on production code. I am pro paired programming in the right circumstances. I found that Working with someone else either driving or navigating, allows you to focus your thoughts more. If you are the one typing code (driving) you are only focused on the lines you are writing and not the lines to come, while your navigator is focusing more on the big picture. This is great! For someone learning to code having to think about less makes the experience easier and more focused. The down side is depending on the pair of people and on how complicated the code being written is. Thus, the level of understanding of each participant in the pair, significantly affects the possibility that two people can write code faster than one.
“It’s more fun than it sounds: two programmers at one computer. One drives; the other navigates. Switching roles fluidly, they constantly communicate. Together, they accomplish better work more quickly than either could alone.” -James Shore, The Art of Agile Development: Pair Programming, February 25, 2010.
If the pair of programmers have a strong understanding of the topic and can write the code with minimum stopping to look things up or to debug, why have two people working on the same code when you could double the productivity and have both people write their own code? On the other hand, if the developers do not fully understand the code they are trying to write, pairing up can be very beneficial. Paired programming will allow the pair to work through problems together, help to fill in each other’s knowledge gaps and hopefully keep the flow going without having to stop for any code-related reason. Sometimes when you are stuck on a bug you get tunnel vision. On that occasion, having someone else there allows you to bounce ideas off of them, and they may have solutions you haven’t thought of, sparking new ideas to overcome issues.
If we are working with a topic that neither person is super familiar with paired programming is great, allowing both people to learn together. If one person has an understanding of a topic that the other person does not, this can allow for great mentoring sessions with paired programming, although slowing the pair down a bit. This type of session becomes a more interactive way of learning than following a tutorial. Code along tutorials have little to no interaction with the person instructing them. With paired programming you can be told what to write, allowing you the time to ask questions and get a great understanding of what is going on with the code. It could also give you the chance to test what you know in the mentor position by walking someone else through a topic they know well. This allows for you to either fill in the gaps of the parts you don’t know or build confidence in what you do know, which is a win win situation!
Another benefit of paired programming is the team building benefits. In today’s current climate most people are working from home and may go days without talking to another person in real life! Working from home has its pros and cons but I feel the lack of human interaction is one of the biggest disadvantages . It becomes hard to build a team or have any sense of connection with another person when you are not seeing them in person. We also know that people are burnt out on zoom calls and no one wants to sit with their mic and camera turned on all day while they are coding. Paired programming forces programmers to be so social with someone else, something that may be a little out of some people’s comfort zone. This is a great way to build a team mentality. Having two people sharing ownership over a piece of code and feeling like they accomplished something together allows the programmers to create a bond with each other hence strengthening the relationships of the team overall. These types of interactions become more important during these work from home times as you start trying to introduce new people to your team and your team’s culture. In 2021 this is going to become more and more something team managers are going to have to think about.
Some other benefits to paired programming that may not be so obvious are that the programmers will stay more focused, less bugs, higher level of code and an overall better output. When we are at home alone we all know how easy it is to get distracted, your phone vibrates or you’re just going to jump on youtube for one video that leads to a lost hour. With paired programming your focus is on the problem at hand, you are in it with someone else and are therefore held accountable.
This brings me to code quality. With two people working and criticizing the code constantly the pair is going to catch more bugs up front and solve the bugs that do arise quicker. With someone else watching over your shoulder you are going to be sure you write better code, as no one wants to be called out for mistakes. With a driver and navigator relationship you are also going to always have one person thinking more big picture, thinking more of the edge cases and the overall code resulting in less janky code. This will allow the overall quality of the code written in pairs to be better quality and less buggy. This results in less time debugging issues and less time wasted on things like rewrites resulting in overall more code outputted by the pair then if they were working individually.
When it comes down to actually sitting down and writing code in pairs there are some things to keep in mind.
- Just like any time you are working with a team communication is key.
- Before you start writing code, sit down with your partner and make a plan. Plan out things like who is going to drive and who is navigation and when you are going to switch.
- Be sure to collaborate on what the main goal of the code your writing is. Break it into smaller problems and write them down so you both are clear on your goals and the order you are going to do them. It is important the pair agrees on these things so there is no conflict or deviation from the plan.
- Be clear when giving instructions and directions. If things are getting muddy and things aren’t working stop and talk it out. It is important to remember you are working as a team to complete the same goal.
Overall paired programming is a great way to produce more quality code. In the days of remote work it is a great way to bring your team together as well as spread knowledge among its participants .
Sources:
Scientific Research
https://tuple.app/pair-programming-guide/scientific-research-into-pair-programming
ENIC Wikipedia
https://en.wikipedia.org/wiki/ENIAC#Programmers
Jean Bartrik ENIAC WOMAN
