Pair Programming
Pair programming is when two programmers get together sharing a single workstation and code together. It is divided into two roles a ‘driver’ and a ‘navigator’ and it is expected for each individual to constantly swap roles every 10–15 minutes.
First off explaining a bit more about the two roles the ‘driver’ will be the one using the keyboard actually typing the code, while the ‘navigator’ will be closely watching every character typed ensuring nothing is skipped and all logic makes sense. This is a beneficial way of coding as it has proven to produce code with fewer errors and bugs.
As a junior developer myself, I have experienced a number of instances of pair programming. Recently with COVID-19 being apparent, pair programming has taken a bit of a spin on itself, rather than myself and another individual programming on one workstation a live share link of the code would be sent out while being on call in order to facilitate what typically should be done.
Pair programming has a number of pros and cons. First off is the opportunity cost of what could have been achieved separately in that same amount of time.
Although yes, pair programming does prove to create less buggy code, if both individuals were working on their own, maybe they could get twice as much done. Of course, it may have a few more errors than if it were to be pair programmed, but the calculation then comes in. Would fixing all the bug from both parties individually cause the overall working time to be increased or decrease?
That is an answer that varies from people to people and situation to situation, but in most cases, it is encouraged to pair program through more difficult tasks.
Looking at the pros of pair programming. Personally, through my experiences of pair programming it has proven to be very useful because the navigator which I am working with removes my doubt when I’m not sure if my logic may or may not work. Having that second voice saying “Yeah, that should work” or “If you add this here it will work more efficiently” is exactly what helps me become more confident in my work and overall work more efficiently.
While I am taking the navigator position and my peer is the driver, that is when I really notice not writing code and just watching it adds a whole new level of caution. Watching every character being typed in while not focusing on what comes next, but instead what is on the document, and does it make sense or is it spelt correct. This is the aspect of pair programming of why it is so widely recommended.
Another benefit of pair programming is that it is also a good medium for relationship building. Getting to know your peers/ co-workers better by becoming more comfortable talking to each other and reviewing each other’s code.
Do’s & Don’ts of Pair Programming
Pair programming is to be tackled while constantly talking. If the navigator is not inputting, then the driver should be verbally walking through their thought process. A don’t, would be simply not talking, constant communication is key.
A do for the navigator is to listen to what the driver is saying and intervene if what the driver is saying doesn’t make sense or there may be a flaw in their logic. Something the navigator shouldn’t do is constantly intervene and tell the driver exactly what to do for example: “Now type for open brackets let i equal 0. Now type semicolon…” As they are the navigator, the driver should be in command and trying to code while someone is just constantly telling you what to do defeats the purpose. Unless of course, the driver askes specifically “Hey, I forgot the syntax of a c-style loop how does it go again?”. There is also something called a 5-second rule if the navigator notices something wrong, wait 5 seconds before telling the driver. They might be well aware they made a mistake or accidentally made a typo and are about to fix it. Having someone constantly nagging them the instant they make a typo can also be quite a drag. Finally, each session shouldn’t be a whole workday. Pair programming for a whole 8 hours can be quite tiring and you have to be mindful of your peer/coworker’s as well, try to implement it into more challenging sections.
Lastly, there is no ‘correct’ way to pair program there are set guidelines and recommendations for how to do it, but at the end of the day it depends on the project and the individual’s style or personality to find the best fitting way to tackle pair programming the most efficient way so don’t stress too much if it’s your first time as you and your partner can find what dynamics work best for the both of you.
References
http://sunnyday.mit.edu/16.355/williams.pdf