Why You should Pair Program
This article will let you know why pair programming will help you become a better developer. It was originally posted on Codementor Rob Simpson‘s blog.
Have you heard that pair programming can be a cause of decreased production?
I have and I beg to differ and will explain why this is, along the way showing the reasons why this is the case. I do this because in my past experiences lately I have been told that I will not be able to take part in pairing with other team members because there is to much to do for the sprint. Little was known about the fact that pair programming can have a huge impact on the quality of code that is produced, decrease defects that are introduced into the code base, and allow developers to get comfortable in working together to see how the code being tested and then written is a good thing.
It is considered counter intuitive to have 2 programmers working on the same code but in reality it can add as much functionality as 2 programmers working solo. This is because 2 programmers working together increases the quality of code that is written, which in the end can save big headaches as the project progresses. One thing to keep in mind is that both of the programmers need to feel comfortable during the session and not take a stance that they are there to analyze the quality of code that is written. Instead, it should be a matter of taking on an attitude of thinking what can be done to increase the quality of code, and have one person being the driver and the other being the navigator. The driver is the one who is currently writing code while the navigator is looking out for errors that could potentially being introduced and how might they come to a better solution if there is one. It is also important for the navigator to keep notes and research possible ways that other solutions have been done previously by other developers. The developers who know how to ask questions instead of critiquing are the ones who build the best code possible.
I learned in “The Art of Agile Development”, that the best possible way to come up with ideas and to exchange the roles of driver and navigator is to think of playing ping pong. This is where the driver will write a test, then the navigator will work on getting the test to pass. This will then be reversed where the navigator will write the test and the driver will come back and try to get the test to pass.
One of the best techniques for pairing is to have it where the sessions are broken up between developers. For a given period of time – say 90 minutes – there are 2 people that work together. After that time the session will end and each of the developers will find others to pair up. This keeps the sessions throughout the day fresh and more eyes looking at the code being worked on.
Keep in mind when pair programming is that the session is not a mentoring session. There should not be a Sr. Developer trying to teach a Jr. Developer. Instead it should be a time to learn from each other, try to solve code problems, and if need be, make an epic where the both of the programmers try to research a solution to the problem. There are times when it is best to take 2 people who have different skill sets and match them up. This way there is a chance for both to learn something new during the session.
The pair programming technique can take some time to get used to and adjust to. Give this some time to allow the developers to adapt to not working solo and feeling comfortable having someone working with them on the code that is being written. Over time the developers will get used to it and like it because they will see a dramatic progress in the time it takes to develop and how much faster they are able to produce the code, all the while making the code more reliable for production release. There will be a short term loss in productivity, but this will be well worth it if you stick to it and get comfortable working with another. The hope is that in the end the code will be simpler in design, have fewer bugs, and easier to maintain.
When developers get together it allows for a training session because both of the developers can learn not only how to code better, but also how to research and code review while the code is being developed.
The best pair programming sessions will come when developers are together working side by side sharing a keyboard. Now there will be times that you are having to remote pair program, and if this is the case, there are some great tools out there that can help you with this process. Build a Command Line Remote Pairing Setup is great for giving ideas on how to setup for remote pairing. See below in the reference for remote pair programming. Having a good workstation for the programmers to work at will make a world of difference during the session, and this includes a larger that cubicle work area, one great workstation, and one or more keyboards and mice. I believe that the pairing session should not have more than one big monitor to work with, as 2 monitors can be distracting when looking at the same code.
The counter to pair programming is code reviews. This is similar to pair programming except for the fact that code reviews are more critiquing that working on a solution in real time. Code reviews happen less frequently and are not so much of a way to instantly solve problems that the code is supposed to do immediately. With a pair programming session, there is a session where 2 developers are working together, side by side, working together to figure out the best solutions for the code that is being written.
One important procedure that should, or must, happen during this time is that no code is written without a test being written first. This goes back to the ping pong technique. Sold code comes from being confident that the code that is being written will meet the requirements of the task. There are debates now as to whether tests are needed before hand, and I am one that believes they are.
In the end, pair programming has advantages for those who participate. Not only is the code going to be of better quality, but there is also a time where knowledge is shared that you would most likely not get if you are are not pair programming. When you have 2 people working together, the 2 advantages above happen because you will stay focused and not find yourself playing around on the likes of Facebook or Twitter when you should be developing.
Codementor Rob Simpson is a Sr. Web Developer at Agilex Technologies with over 15 years experience in web development, and his last few years have been focused on BackboneJS and AngularJS projects.
