How do you Pair Program?
Recently I was asked to answer this question in order to provide feedback on the Pair Programming curriculum at Practicum by Yandex, the school at which I’ve been studying full-stack web development for about five months. Throughout my studies, I’ve been attending weekly webinars intended to teach the practice and methodology of Pair Programming.
The feedback is meant to I figured this would make for a good blog post, a place to discuss what pair programming is, why it’s useful, and how to do it.
What is Pair Programming?
Pair Programming is a software development technique in which two developers work together on the same codebase simultaneously. That, as a higher level explanation, may seem obvious, but Pair Programming as a practice can take many different forms. I’ll split up methods of Pair Programming into two broad categories that I’ll call “Practice Pairing” and Objective Pairing”.
Like all skills, learning to Pair Programming requires repetition and exercise so to speak. Practice Pairing occurs when two developers meet up to to flex the mental muscles used when working with another developer. I’ll get into why this practice is important, and how one might engage in this practice later in this post. For now, understand that practice programming is meant to take place in a safe space where mistakes are expected, it’s supposed to be fun.
Objective Pairing is what all that practice prepares you for, it’s when two developers combine skills and brain power in order to bring more resources towards tackling a problem, or achieving an objective with code that is intended to be deployed to production. Again, I’ll get more into the why and how in the next few sections.
Side note: “Mob Programming” is development practice when many developers work on the same problem at the same time at the same machine. Mob programming can be chaotic in the best ways and can be lots of fun. I won’t discuss Mob Programming here but I want to encourage all readers to give it a try at some point.
Why is Pair Programming Useful?
Generally speaking, it seems as though the learning process of programming entails a vast majority of time where you are the sole developer working on a problem. Once you begin working in the tech industry, that is rarely the case. Whenever I get a chance to ask professionals about what their day to day life is like on the job, I inevitably hear about their team and their interactions with their teammates.
There’s a simple reason for this: two (or more) heads are better than one. Each team member can approach a problem with a fresh view and can bring their own unique knowledge and experience the initial developer might not have themselves.
The teamwork can take on many forms that vary in scope and synchronicity, which I will get into in the next section, but one thing is for certain, teamwork happens.
How does one Pair Program?
This question is the meat and potatoes of this whole post, as there are a few sub questions that I want to address within this section. After a brief discussion on roles, I’ll split this long extended answer in to subsection, talking about Practice Pairing for the initial answer, and Objective Pairing for the rest.
Pairing Roles
Traditionally speaking, Pair Programming splits up into two roles: Driving and Navigating. The driver, much like in a car, is the person who has hands on the problem. They are the one with their hands on the keyboard writing the code. The navigator, again much like in a car, is the one making the decisions on where to go and what to do. They tell the driver what code to write. Sometimes these roles dissolve and both developers act as the driver, working on editing the same codebase from two separate machines. I’ll discuss how that looks later on.
Practice Pairing
When should I Practice Pair? Practice Pairing can occur as soon at any stage in your learning process and is a great way to get used to working with another person on the same codebase, something that might be surprisingly difficult for some. Some of that difficulty might include some semblance of performance anxiety, the fact that up until your first pairing session, you haven’t received live feedback on your thoughts and ideas with regards to coding. Hearing someone agree or disagree with your ideas might be a little jarring at first. Another thing that might be difficult is the process of ceding some of your control over your code. Up until your first pair you’ve been in 100% control of your code. For someone that feels confident in their own abilities, it might be difficult to approach a problem from a different angle than you would have on your own.
Both of these challenges are hurdles that every developer, or every teammate no matter what field you work in, must get through. Simply put, we don’t know what we don’t know, and pairing is a fantastic way to fill that gap in our knowledge by actively learning from others. Pairing early and often in your learning process can only benefit you down the road.
What do I need for Practice Pairing? Practice Pairing can take many forms but generally speaking the only tool you need beyond internet connection is some voice or video call software, ideally one that allows you to share your screen. I’ve used Slack, Google Meet, and Zoom in the past and think that all do a great job at providing a cheap and easy way to connect. If you’re located in the same place as your peer, forget all about the software and get right to it!
How do I Practice Pair? With a small list of required resources, Practice Pairing is easy to set up! Of course you will also need an idea of something to do. In my experience, Practice Pairing is most successful when the activity is centered around something fun. Abby Fichtner has a great article written by Moss Colum and Laura Dean about some fun ways to code with another person. The article discusses some ways to create games that a designed to aid in the learning process.
I’ve found that it’s fun to find a small problem to solve, something that can be done within an hour, setting a time limit in which you’ll attempt to solve it as a pair, switching roles halfway through. Places that I’ve found interesting problems to solve are Leetcode, CodeWars, and CSSBattle. Leetcode and Codewars are more geared towards answering questions you might find on an interview, whereas CSSBattle is a place to practice replicating images with pure CSS. All three are great places to practice skills in an environment built for learning. One important note here is not to be afraid to ask a search engine for help. If you’re navigating and you’re not sure about an array method or a CSS property, ask your driver to look it up! Remember, it’s all about learning.
Objective Pairing
When should I Objective Pair? So you’ve spent all that time practicing and now you’re ready to pair program on some production code. Incredible. I’ll cover three situations where Pair Programming can be handy.
When you don’t know how to do something — I’ll be honest. This happens often. Just recently I was working on creating a draggable carousel display with a custom scrollbar using Vanilla JS and I spent more days looking at the design brief than actually coding anything before realizing that Pair Programming was the solution. What was slowing me down was that I perceived there to be many moving parts, all comprising topics I was unfamiliar with, and that led me to procrastinate or sink into a cycle of deadend research. When I finally got started working with a partner, we were able to split up the task into bits and work slowly through each component. Sometimes we’d work on our own, with nothing more than the keyboard clacks being shared over the video chat. Other times we’d come together, split into the roles of Driver and Navigator, and let our shared knowledge carry us over hurdles that we’d feel powerless to on our own. We got the carousel done in a few hours, which still seems to me like a miracle. In this situation, our combined knowledge of Vanilla JS was able to make the production process far more simple than it would have been had we tackled it on our own.
When you want something done right — We’ve all been in a situation where were nearing the end of a task or project and you can feel the motivation and attention to detail begin to wane. Whether due to a loss of focus, interest, or confidence, it’s not rare to find yourself making small errors as a task wraps up. Sometimes those mistakes happen early on, and sometimes you’re not even aware you made mistakes in the first place. In any case, situations like this call for a fresh look from a peer to provide proof reading and feedback. Code Reviews are a typical method of providing said feedback. Before any code is merged into a production branch, the code must be looked over by a team member. This team member keeps a lookout for code errors, and general ways that the code might be improved upon. Where pairing comes into play here is when Code Reviews are able to occur face to face. The reviewing, in this situation, takes the role of navigator, and the author of the code takes the place of the driver. The reviewer will read through the code and ask the author to make changes in real time. Asynchronous teamwork allows team members to work at their own pace and their own schedule, but occasionally that means a less efficient workflow. Pairing while running a Code Review allows for more synchronous workflow in which errors can be fixed as soon as their made.
When you want something done fast — Say you’re in the middle of a sprint and feel like you still have a world’s worth of work in front of you. That can be a tough mountain to climb on your own. Pair Programming, getting together with someone else, is a great way to stay focused and motivated as well as prevent yourself from entering a cycle of doubt and questioning. I’ve used this method of pair programming during a Hackathon during which my partner and I split the project (a landing page) into blocks and worked on the same files simultaneously. I’ve also worked through difficult portions of projects where one partner works on the CSS while the other works on the HTML. In any case, two heads are better than one and four hands are faster than two.
What do I need to Objective Pair? Beyond an internet connection some video sharing software, You need both a place to write code together and a place to review code.
Writing code — There are a fews ways to go about writing code in the same place. The most accessible way that I’ve found is to use an in-browser Integrated Development Environment (IDE) such as Repl.it. This method doesn’t require you to download and install any extra software and is relatively easy to set up. The downside is that if you’re hoping to work on a project that’s already written elsewhere, there’s an added (rather difficult) step of copying over the necessary code before and after the paring session.
To prevent such a hassle, I like to use Live Share, a plug-in built for Microsoft’s Visual Studio Code, a common IDE. Using Live Share allows partners, provided they’re on the same IDE, to work on the same code at the same time and view changes in real time. The host of the session can also share a local server with the team which allows partners to see changes to the project live in-browser, as well as in the code. A benefit to using an a plug-in such as Live Share is that it doesn’t require you to learn how to operate another system. You can stay where you’re familiar, and work as fast as you’re used to.
Drovio is another fun way to have your team all work on the same machine. with this software your team will all have access to one machine. Picture many computer mice travelling across the screen clicking on and typing whatever they want, that’s Drovio.
Reviewing Code — All you need to review a peer’s code is the platform on which your source code is hosted. Hop on a video call after you or your partner submits a pull request and you’re on your way to a paired code review. If by chance you’re using Github to host your source code and Visual Studio Code as your IDE, there’s a another fantastic extension you might want to use to do said code reviews in a familiar setting.
How do I Objective Pair? As mentioned above, how you chose to pair largely depends on why you chose to pair in the first place. If you need help tackling a problem, it might help to bring on a peer as a navigator while you drive. If you need something done fast, it might make sense for both partners to act as both drivers and navigators for their own subsections of code. If you want something done right, invite a peer to review your code once you feel like it’s ready to ship. In whatever case, make sure you enter the session with a time limit (might I suggest the pomodoro technique)and a clear distinction of roles. It’s ok to let those things change, but setting them ahead of time is a nice way to get on the page with your partner as to what each of your expectations are.
Conclusion
By now, I hope that it’s clear that Pair Programming is a useful skill that can help move production along in many scenarios. Whether your pairing to practice or pairing for production, working with a partner can help you learn things and write better code faster. There are many tools out there to help you Pair Program which means that getting started is easy. If you have any interest in moving forward into the industry of software development, Pair Programming is something that you’ll see early and often.
Find a friend, get pairing, and have fun!
