I had never heard of pair programming until I enrolled in an online web development bootcamp. I didn’t really enjoy group work back in university, so by the sound of it I thought that this wouldn’t be right up my alley. However, when we all had a pair programming session on the third day of bootcamp, I fell in love with it!
The Wikipedia page for pair programming summarizes this concept very well. “Pair programming is … [a] technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in.” There is a few styles of pair programming techniques, but the only one I have experienced is the driver-navigator technique. Of course, not everyone is sold on pair programming, but certain companies use it on a regular basis.
Now, due to COVID, I have only done virtual pair programming, not in person. The sessions are set up with either Discord or Google Hangouts and we would share screens using VSCode Live Share. Below are some thoughts I have about pair programming. They are purely based on my experience.
Choosing someone to pair program with can be tricky. If the knowledge or experience gap between the pair is too far apart, the workload wouldn’t be balanced. The more knowledgeable person would usually be guiding and spewing out ideas the whole way without the other person doing much work at all. That can lead to the former person getting exhausted much faster than the latter.
On the other hand, if both people are at the same skill level, most of the time both will be stuck at the same point of the problem without having any ideas for a solution. An outside help will be needed to move forward. The tricky part is, there are times when immediate help is not available, so a bit of time will be spent waiting for help.
In the online bootcamp I attended, it could feel awkward to have to pair program with someone we have never talked to and have never met before. However, in the end, we are both working towards the same goal and we just need to find a way to work together.
In addition, sometimes pair programming sessions can feel mentally demanding. If one is not a talker, it might be difficult to have to keep saying ideas out loud and narrating what is going on throughout the session. That would lead to burn out more quickly. There are times when one person would like to tune off and take a break, but the other pair would still like to keep going. In this case, the answer is always compromise. In my opinion, it is better for both to take a break rather than have one person with a decreasing quality of work.
Another quirky aspect about virtual pair programming is that it relies on the internet connection. There are times when the connection is not really reliable, then the audio would sound distorted or the screen share would suddenly go blurry. That will make the driver clueless about what the navigator just said seconds before or cause the navigator to have to pause for a bit to wait for the code changes to render on the screen.
I have learned so much from pair programming. It definitely helps each other pick up new skills and best practices faster than reading resources and watching self-help videos. It is also a good practice for both people to hone on some coaching skills, like explaining new concepts in a way that is easy for the other person to understand. With virtual pair programming, this becomes a true test of verbal communication skills because most of the time both people cannot see what each other is doing.
When pair programming, usually there is a level of accountability for both people to focus on the code, of not wanting to let each other down, and as a result both get distracted less. Motivating each other to push through adversity is always encouraging and boosts morale, especially when doing a virtual session after a long time in isolation during COVID.
Another aspect I really love about pair programming is that most of the time typos can be immediately caught! So much time is saved from a potential debugging marathon caused by misspelling, missing words, missing brackets or missing semicolons. Research done by Williams, et.al. (2000) showed that pair programming had higher percentage of test cases passed compared to when programmers worked on the tests individually. Two pairs of eyes is better than one.
If this is your first time pair programming, try some of my suggestions below.
- If you are doing virtual pair programming, I would strongly suggest a good internet connection and a pair of good headphones with a microphone to make the process smoother. A pair of earphones can also work, however I notice that my ears would hurt after a certain amount of time from having to hold the earphones in. Use Discord or Google Hangouts for audio and video of the front camera, then share the link to the VSCode Live Share. Split the computer screen into halves, with the left half showing the front camera and the right half showing the VSCode. When pointing out a specific code, always mention the line number instead of trying to explain where it is (or even pointing at the camera with your finger 😂). That way, both the driver and the navigator have a clear idea of where to look. Otherwise, when possible, do in-person pair programming since that would allow more body language to be communicated clearly.
- In my experience, selecting a partner whose skill level is about the same or just slightly above would make the most fun pair programming sessions. In my online bootcamp, when both people are stuck on the same problem, there is always someone else to reach out to. Then, both people would be able to explain to each other the new concept that was just presented and further cement that knowledge.
- As discussed above, pair programming can feel taxing on the mind. Taking breaks often would help with that. Some would take a 10-minute break after an hour of work. Some would take a 15-minute break after two hours. Find what works best and agree on it.
- Don’t stop talking. The minute one person stops talking, the other person would not know what goes on in the first person’s mind, especially if you are doing virtual pair programming without front cameras on. When one gets stuck, instead of keeping quiet, try asking questions, such as, “Could you assist me?” or “What plan do you have in mind?”
- As a navigator, know when to intervene. As a driver, know when to give the keyboard to the navigator. This will help save time in solving problems and debugging where only one person has an idea of how to move forward.
- To keep things fresh, switch roles often. It can be for every block of code or every few minutes.
Sometimes talking through problems with another person can bring out a solution in less time compared to solving problems alone. The key is to always communicate and not hesitate to ask for help.