Pair programming is two coders working together at one workstation on a single piece of code. Done well, the coders sit together and discuss the project and break problems down together. Pair programming puts into practice the notion that two heads are better than one. You're constantly rubber-ducking[1], ultimately writing stronger code while learning and staying focused on the correct problems.
We are obviously fans of the pair programming approach, and feel it can be effectively applied both on-site and remotely. However, “traditional pairing” does have downsides.
- Not all tasks when building a feature are best solved by two minds working together (sometimes you're better off splitting up temporarily to try multiple solutions, sometimes it's just busy work after the pair makes a plan).
- When pair programming remotely, screen sharing can be laggy.
If you are a manager assessing the use of pair programming, or a coder looking to utilize this approach effectively to boost performance, we’ve found VS code (with the VS Live extension) to be a valuable tool for tackling the shortcomings of the pair programming dynamic listed above.
Let’s talk about a morning we (Dave and Justin) had recently:
Justin: We had a pretty productive morning where we got to pull together a bunch of stuff that we both had been working on over the course of the week. It’s 9:43 a.m. on a Friday, and we had a pretty big to-do list carried over from the day before:
- Finish extracting a presenter
- Fix 20~ tests
- We also had another piece of functionality that we needed to finish before we were finished with the feature that we were refactoring (adding spinner)
We started out together and busted through the extraction of the presenter. Even though we were working on the same feature, we weren't really looking at what the other person was doing. Dave would work in the test file, while I would work on hooking it up in the component.
Dave: Yeah, the extraction was the kind of task where it was nice to have two sets of hands typing at the same time. We decided which functions to extract together. But once we agreed on the plan, it was faster to actually do the extracting separately at the same time.
Justin: By about 10:37 a.m., we finished with the presenter. We were both super pleased with how it turned out and planned to reuse this pattern going forward (faster tests, simpler logic, etc.).
With that checked off our list, I wanted to get us back to green (no one likes having so many test failures looming over your head). So, I open up a test file and get to work.
Dave: While Justin worked on the tests, I got into working on the spinner since I thought it was important to at least start working on that before too long.
Justin: At 10:53 a.m., I got stuck with some test setup and asked Dave to “pin me” (in VS Live you can click a button in the upper right hand corner to follow around your pair, so if Dave pins me then his screen will immediately be my screen).
We tried a few different things together (Google searching and such in between). Finally, Dave decided to go back to the spinner, and I paused for a second and decide to try "just one more thing."
Dave: I went back to working on the spinner to finish it up. It ended up being a pretty straightforward task; and it was nice to get that off of our to-do list while we were troubleshooting the test setup.
Justin: Then this “just one more thing” ends up working, and I finish writing the test. During this time, Dave announces that he finished the spinner. Since this means we are now feature complete (and since I had no idea that he had ever even started working on the spinner), I’m pretty stoked.
We start working on fixing the failing test files together. By 11:33 a.m., we finish everything we needed to for the week and push our code up for review.
So, how did VS Code / VS Live help in this situation?
Typically, each of us starts up VS Code on our own computer and one of us starts a VS Live “session” that the other person joins. The host person then shares a terminal to their computer that the remote person can access, and also shares the port on which the app is running.
So now, even though the app and code live on the host’s computer, both participants can edit the code using their own VS Code instance, and can send HTTP requests to the app using their own browser. And because each person is running their own VS Code instance, they get to use their own IDE settings (keyboard shortcuts, vim/Emacs bindings, etc.).
Going back to the assertion from above. Some tasks are better solved by two people working together, and others are best solved by two people separately. With VS Code / VS Live, the transition between the two workflows is seamless (because each person has a cursor / context).
It is effortless to separate for a while and then help each other when you need to or, when necessary, team up on a single piece of code and do more of a traditional pairing approach.
It seems like something like this would be laggy? How’s the performance?
We’ve used other tools for pairing previously. These include screen sharing / remote connection programs that let you see the browser and have access to everything, but can be taxing on our computers and laggy depending on our Internet connection. We’ve also used tmate and vim for pairing, which is much less laggy, but only lets your remote pair see what’s in the terminal window (no browser access). The remote Live Share coding experience is much more like that of tmate (not sending as much data as a screen share would) combined with access to your own browser.
Here is a chart:
Key Takeaways
We believe pairing is important. Coders do their best work when they are inspired and equipped with the right tools and resources. Pair programming allows for better information sharing, solving problems more quickly, achieving a deeper understanding of the system by multiple people, and improving team dynamics.
VS Code just upgraded pair programming. Not only does it make pairing remotely smoother, it also allows pairs to accomplish the less complicated tasks quicker. If you have been hearing good things about pair programming and want to try it out on your team, there has never been a better time to get into it.
Notes
[1]Rubber-ducking is when you ask another programmer for help. But in the process of describing the problem you are trying to solve, you end up figuring it out yourself. This happens frequently enough that we have a saying for it: “If you get stuck, pretend you have a rubber duck on your desk and then describe the problem to it.”
