Pair programming is a collaborative software development approach where two programmers work together on the same task. One programmer, the “driver,” writes the code, while the other, the “navigator,” reviews the work and provides guidance.
In practice, it’s best for pairs to switch roles periodically. Since this process can be mentally demanding, shorter, time-boxed sessions often yield better results than long, exhaustive ones.
Pair programming offers numerous benefits, including improved problem-solving, enhanced knowledge sharing, and cleaner, more refined code. Collaborating with a partner often leads to better outcomes than working alone.
This post explores pair programming at a high level and shares insights from real-world experiences with implementing it in professional environments.
Collaboration is essential in modern software development, especially with today’s increasingly distributed teams. Maintaining alignment can be challenging with team members often spread across different cities, states, and even countries. Pair programming serves as a powerful tool to bridge these gaps, fostering stronger collaboration and more cohesive teamwork.
When conducting pair programming sessions, developers get the chance to comfortably share knowledge and accomplish tasks in a way that allows work to be done and general learning to occur.
One caveat to pair programming that I’ve seen is that it always requires a “safe space” for people to work in. When you pair program with team members, the environment needs to be comfortable enough that everyone can feel comfortable speaking and being heard.
If the environment is even a little bit uncomfortable, let alone hostile, the work will not be done right. All this touches more on team dynamics, which are beyond the scope of this post. In short, a good working environment is essential for success.
I’ve seen several variations of pair programming in my different professional roles throughout my career. More often than not I’ve also seen “mob programming” or “mobbing,” where an entire team works together on a task.
Most of the teams I’ve been on have consisted of one to five people. In that context, mobbing can be managed. I imagine if there was a much larger team, this could get unruly.
My current team has seen great success with a mixed approach between pair programming and mobbing on tasks.
In my professional role, I’m a tech lead of a product team that owns an application used nationally by a large company. The product is high visibility and a critical function to the business.
I joined the team after the product matured over the course of a few years and different leadership contingents. Given the importance of the product, the team had become siloed and focused on tasks rather than working together.
There were several knowledge gaps on the team, due to different amounts of tenure with the product. Given these factors, I started trying to host pair programming sessions — which were really “mobbing,” as I mentioned in the earlier section.
Our team started with each session structured as a time for one of the developers to share what they are working on or get feedback on some specific topic. This was helpful initially because we could fill in gaps in our knowledge, where we previously only had one person who knew about a topic.
From these early sessions, we then attempted to “mob” on tasks. We picked cloud-based topics like building infrastructure, or refining configuration for a resource. We even did a session where we evaluated our disaster recovery strategy, which turned out to be a wealth of knowledge for us to grow as a team.
All of these early sessions started to build the safe space that’s so essential for effective pair programming. This helped individuals gain more skills in areas outside of their expertise and generally made tasks more fun to work on.
Over time, team members also started to have smaller pair programming sessions for specific tasks. As a team, we continue to have the larger group “mobbing” sessions.
The big takeaway from this work was that focused collaboration made our product and our team better. It’s easy for teams to become siloed and just focus on “keeping the lights on.” However, in that mindset teams never move on to something greater.
It’s important for teams to do their work, of course. But it’s also essential for them to be aware and receive chances to grow outside of the specific thing that they’re asked to do.
Pair programming really helped our team to become more well-refined, and in turn, our product (and future enhancements) have become more robust and made better use of trends and best practices in the industry.
In my career, I’ve had multiple experiences with pair programming. Here are some of the lessons I’ve learned:
If you Google “pair programming,” you often see tactics like implementing time constraints and other general rules for productivity. What I have found with smaller endeavors is to cater the sessions to what works best for the developers involved.
It helps to:
I’ve gone with the stereotypical experience where two developers sit side by side. I’ve also had the opportunity to use a variety of tools to pair programs virtually.
With the team I lead professionally, I’ve found that simplicity is the best option for pair programming.
There are a lot of powerful collaboration tools that you can use. However, just talking and doing a video call works in most cases. We use Microsoft Teams, so we’ll generally have a Teams call and then whoever is the “driver” shares their screen. In most cases, this works fine — as most of the time, the people in the “observer” role can articulate the change to be done.
It’s also helpful to have some form of visualization software available. Most of the time I use draw.io because it is free. I’ve seen teams use many other applications like Miro and other platform-specific tools built into things like Microsoft Teams.
When working virtually, you often need a “whiteboard” area to describe concepts. If you’re working in an office, this can obviously be done with a real-life whiteboard. But in virtual collaboration, you’ll need a tool to accomplish the same task.
Here is an example flow chart from an application. This is pretty similar to the format that you would see if my team needed to diagram out a process flow.
Time management is also key to my team’s success with pair programming. Task management software can aid in what you do during your pair programming sessions.
Azure DevOps is more than just a task management tool, it also works effectively for my team. We use the “Boards” component of Azure DevOps to track agile stories that our team works with.
We usually pick a story from our board and pair on that. Azure DevOps also includes a wiki feature, which is super helpful for maintaining team documentation. If we’re unable to complete a task during a session, someone will document what was done either in the story on our board or in our team’s wiki.
An example of what a board looks like would include stories in the different swim lanes between things like “in process” vs. “released”:
We use notes in our stories to pick up where we left off. If the task is something that someone can “take off and run with” afterward, that also works. The team will just hand it off to an individual to finish up. Taking my example board screenshot, here is what a story with some comments indicating progress would look like:
It‘s also important to have someone who can facilitate the sessions. If you’re working one-on-one, this is easy; it’s just you and your coworker.
If you’re in a larger group, it helps to have someone who can focus side conversations, and at the very least bring everyone back to the task at hand. The focus is an important part of success with these sessions.
This doesn’t have to be overly formal. You just need someone who can always bring conversations back to focus. I usually hold this role with my own team. However, different team members can do this at any time.
It helps to regularly “change hands” during pair programming sessions, i.e. swapping team members between being the “driver” and the “observer.” If one person is always the one doing the actual code changes, it can be exhausting — and they also don’t get the opportunity to analyze what is being done.
Making sure that everyone feels heard is really important in these sessions. The idea of a “safe space” is crucial to success. It’s vital not to speak over individuals, or make people feel like their ideas are not valued. Everyone needs to feel empowered to discuss and contribute to the sessions.
Pair programming sessions can tend to use up a lot of energy. You have a lot to track between the task being done, the conversations about the work, and also being aware of your progress.
It’s important to be aware of the energy of your team. If you feel like the other person (or team in a “mobbing” session) seems tired, then find a good place to take a break. When you get exhausted you generally do not make good decisions, and it’s really just not fun for anyone.
In this post, I discussed pair programming and what has worked for my team professionally. I briefly introduced “mobbing” and also talked about the team dynamics that need to take place for success. There are many different process ideas and considerations you need to make for each session to be successful.
Every team is different, and all of these things will cater to the best environment that works for each team. My team has had a great experience with pair programming and has found that it generally helps not only our productivity but also makes working fun.
I highly recommend trying it out, and seeing if pair programming works for you. Thanks for reading my post!
Hey there, want to help make our blog better?
Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Sign up now
Discover open source tools for cross-browser CSS testing like Playwright and BrowserStack to catch rendering errors, inconsistent styling, and more.
Build a TypeScript ETL pipeline that extracts, transforms, and loads data using Prisma, node-cron, and modern async/await practices.
Looking for the best React charting library? Compare the latest options, from Recharts to MUI X Charts, and see which one fits your project best.
Explore why the TypeScript team is porting the compiler to Go in TypeScript 7. Learn how this shift impacts performance, tooling, and the future of the TypeScript ecosystem.
Learn more →
