For many, web development is envisioned as a solo sport. They picture a person sitting alone at a desk, maybe at home or in an office setting. They’re likely jamming out to music through headphones while their fingers type quickly and efficiently on a keyboard, working some logic problem before them. This is the picture I had in my head when I was first introduced to the web development world and it thrilled the introvert inside me. On the flip side, it also terrified me because web development was new to me and new adventures can be scary on your own. Turns out, web development doesn’t always have to be a solo sport — let’s queue up the concept of pair programming.
While there are different approaches to pair programming, the basic definition remains the same. Pair programming consists of two developers working on the same code file. This could be in person on the same machine or remotely using programs such as VS Code LiveShare. You generally have one programmer as the “driver” who is manually typing code and another programmer who observes and “navigates” for the driver.
The idea is that the workload is shared between the pair while also encouraging each to share their techniques and knowledge with the other through the process.
“Driver-navigator” pairing involves two programmers frequently switching roles between driving and navigation. The driver in this method communicates his ideas while coding them and the navigator observes each line of code for syntax and consistency. While observing, the second programmer also acts as a navigator, considering the strategic direction of the work and offers suggestions for improvements. This approach allows the driver to isolate their focus to the tactical aspects of the code they are writing. It relies heavily on good communication from the driver or the navigator may get lost or disinterested in what’s being coded.
“Strong Style” pairing also alternates between driver and navigator roles but provides the navigator with increased responsibilities. The navigator is responsible for telling the driver exactly what to do and the driver must follow their lead. All ideas must come from the navigator and are to be translated into code by the driver. This approach can help to keep the observer/navigator more engaged.
“Ping-Pong” pairing involves having the driver draft tests for behavior and asks that the reviewer apply the behavior to satisfy the tests. These roles are switched back and forth with an increased focus on refactoring both the behavior and tests, aiming to simplify and optimize the code.
After reviewing this topic and in particular the comment sections following other articles written on pair programming, it became increasingly evident that not everyone is on board with the concept, and implementation within companies can be a controversial subject.
Those opposed to pair programming feel that the practice allows developers with less skill to hide behind their more experienced counterparts. Another opinion in opposition takes into account different personality types and reflects that some people have social anxiety and find the idea of pair programming quite distressing.
Those in favor of pair programming advocate that it produces better code that is easier to read and understand. Apart from producing high-quality code, pair programming provides an opportunity to pass on knowledge from one developer to another.
Through a 12-week intensive web development boot camp offered through Lighthouse Labs, I was able to experience pair programming a handful of times with various partners. My first thought entering a paired programming kata challenge with another person was fear-based — surely my skills wouldn’t be good enough and I would end up frustrating the other person while embarrassing myself. I was nervous and wanted to avoid the whole thing entirely, this was my introverted self-talking trying to sabotage my experience before I even attempted it.
In reality, the way I felt through the experience was completely opposite of my expectations. Though my experience did indeed start with nerves and anxiety, those feelings were quickly replaced with relief. Turns out my first partner felt the same way I did, we were both trying to navigate new waters and in the end, after seeing this in one another, we became each other’s greatest supports. We were able to learn, and admittedly fail too, but overall it felt less stressful to approach a challenge with another — it felt good.
Throughout the boot camp, I practiced both traditional and strong-style pair programming and became a big fan of both. I’m new to coding, so some might say this affinity for pair programming is helping me shield my lack of skill but I would have to disagree. I learned so much from my partners in each experience and I felt comfortable enough to share my knowledge with them which in turn helped me to solidify my own learning further. The golden rule of “see one, do one, and then teach one” holds true with pair programming — but the beauty with this technique is that all three are wrapped up into one great process for both individuals involved. If they can decide to let their guard down, enter with an open mind, and remember that at the end of the day nothing can be lost in the process, they may just realize there is so much that can be gained.
The practice of pair programming can have a positive impact on a company as well as the employees who work there. There are many pros to pair programming; major ones include producing higher quality code, offering a platform for colleagues to exchange knowledge, and integrating both positive and improvement feedback between colleagues in a safe space. In order for pair programming to work, its implementation must be strong through company culture. Without solid implementation, employees may feel anxious or disagree with the practice and without their participation, the whole practice can fall short and fall apart. Pair programming can be an intimidating process but if those who are intimidated can lower their guard and give it a real shot, they just might grow to love it as I did.
I hope you enjoyed the read! If you have any comments/questions or would simply just like to connect, you can find me on LinkedIn.
— Katie Herda
Weblab Technology (2018, January 25). Tuple’s Pair Programming Guide. Retrieved November 12, 2021, from https://medium.com/@weblab_tech/pair-programming-guide-a76ca43ff389
Pair Programming Guide. Retrieved November 12, 2021, from https://tuple.app/pair-programming-guide/
McDonald, K (2017, September 14). 2 Tips to Make Pair-Programming Less Scary. Retrieved November 13, 2021, from https://www.thekguy.com/2-tips-to-make-pair-programming-less-scary.html
.png)
.png)
.png)
.png)
.png)
.png)
.png)
%20v2.png)
.png)
