A few years ago, within a couple of months, I experienced the two extremes of pair programming. On one hand, I still had a fresh memory of a highly collaborative environment which encouraged engaging in mixed coding and ideation sessions that often led to making rapid headway. It had a healthy focus on results without an obsession for rigid processes and oversight. On the other hand, I was suddenly facing a substantially different one, dominated by performative actions, and where constant negotiation and appeasement of existing hierarchies were the daily norm.
It's no wonder that for the following year, I dreaded the experience, finding it intrusive, highly uncomfortable, and unnecessary. Making matters worse, the social contract of the latter space promoted mutual fear as a prerequisite for success. It had a somewhat dismissive view of direct collaboration, often regarding it as wasteful, best reserved for cases indicating individual failure.
Such situations make it intriguing to explore some of the factors that influence company cultures' stances on pair programming along with the potential benefits they overlook when dismissing it based on a superficial, one-size-fits-all assessment.
Reluctance and Resistance
In highly structured, metric-driven environments which lack extensive experience with this, pushback is likely coming from both the organization and individuals. For contexts where numbers are the be-all and end-all, this change requires a leap of faith, potentially obscuring valuable but less visible work and causing fear that a significant portion of impact may become invisible. If things fail, somebody will have to take responsibility and there aren’t normally many volunteers brave enough to do that. This fear, while valid, can be dangerous.
Companies often view intangible aspects as liabilities, regardless of their intuitive sense. Lack of visibility is linked to wasted resources and people exploiting the system, while also being perceived as a missed opportunity for additional cost-cutting. In itself this is potentially indicative of larger issues like unreliable recruitment and misguided culture, which might warrant a separate discussion.
However, distrust within organizations forms at the confluence of individual fears. After all, no matter how great the “family”, when things go south, you’re on your own, kid. That’s even more so, after a couple of years experiencing lay-off season every other quarter. So it’s unsurprising to notice pushback when you combine the fear of ridicule and retaliation with the perception that sharing your knowledge is giving away the little competitive advantage you might have left. A mix made in heaven, not very conducive to building a robust, innovation friendly culture just ripe for creating that highly elusive stakeholder value. More is always more.
Now let’s take a brief look at what’s to gain. This is one of those activities that happens to be both intrinsically personal yet collectively beneficial, but you’re likely to get the best of it if you understand and respect it for what it is. As with everything human related, there’s a spectrum of perspectives, which means you’ll have to trust the process first.
In return, when done for the right reasons, you get to enhance your team dynamics by unlocking latent interaction patterns that can support your internal processes from the very early stages of recruiting up to delivery and maintenance. It can have a tremendous effect during onboarding by allowing existing members to get a fresh angle on their work, should they care to hear it, while simultaneously allow new members to fast track their introduction to the new system and what it’s like to produce quality work. A stark contrast to going alone through, sometimes, vast amounts of occasionally outdated documentation.
The natural direct consequence is that it also helps build trust and familiarity faster, which, in turn, can have a positive impact in terms of work life balance. For day to day activities, it helps to provide a more even spread of information, avoid blind spots and reduces the likelihood of information loss when team members depart for greener pastures. It can also help speed up things by averting costly refactoring sessions due to undetected suboptimal early design choices or solutions that only emerge during code reviews.
That doesn’t come without risks, but these are more a consequence of how you use this tool rather than its inherent flaws. First of all, this is a double edge sword in the sense that it requires a certain level of openness. As much as it is an opportunity for honest conversations, it can also bring light on less palatable aspects of working together. Then again, those pain points are still going to surface, just at a slower pace. Without a proper set of healthy guidelines and support it can also easily backfire, negating the intended outcomes.
If the internal culture highly prioritizes conformity and social harmony, then it’s likely to encourage strong consensus which in turn negates some of the benefits of having opposing views and exploring ideas through constructive friendly debate. There’s also an equally high risk of losing focus and developing pair programming fatigue when its being overused, especially in high pressure projects with tight deadlines and high feature churn.
Making it work
What led me to reconsider my stance and embrace pair programming as a valuable development approach even in spaces which discourage it? This transformation certainly didn’t happen overnight. In fact, the whole transition unfolded over the course of a couple of years. A new team and a gradual release from imposter syndrome significantly influenced my openness to engage more deeply in this collaborative work style.
It took me a few sessions to understand that this environment was genuinely safe, a results-oriented culture that valued each member's contributions rather than watching out for the things they lacked and centering mostly on this part of the process. Once again, things were starting to feel right.
Let’s see what was different. First of all psychological safety as part of a blameless culture was more than just a simple click bait headline. A reliable indicator of its enforcement is observing behavior during substantive disagreements. And there were a few big ones. This is especially true when power imbalances do not enforce superficial politeness. Additionally, the manner of feedback is crucial. While what is addressed is important, how and where it is delivered is more indicative of a how healthy a culture communicates. This aligns with effective conflict resolution skills that avoid hostility and aggression.
Notwithstanding these factors, it would be remiss not to acknowledge the role of luck in successful pair programming. While one can cultivate sociability and agreeableness, personal chemistry is largely a matter of chance. If it’s there, it can really make things so much better.
How has this played out in practice? While every session is different, there are a few things that stand out. Firstly, it's essential to consider the roles of seniority and skill sets within pair programming and their impact on particular scenarios. Pairing developers of similar seniority levels serves different objectives than pairing those with varying levels of experience. Similarly, tenure matters as it relates to the depth of knowledge each developer brings.
It can also have an interesting side effect on managing imposter syndrome by showcasing a more honest, unfiltered take on each one’s abilities and where they fall short. After all, it’s always mindful to think twice before labelling anyone as either a 10x developer or a rookie. Instead, you’re more likely to simply experience differences in masking professional inadequacies and insecurities.
Selecting skill overlaps or complementary skill sets benefits in distinct ways. For instance, varying seniority or tenure facilitates knowledge transfer and redundancy. Conversely, developers with a diverse combined skill set can tackle complex issues requiring broad contextual awareness. Moreover, this can serve as trial runs when choosing long-term pairing partners.
There are also several common variations in pair programming dynamics, which can sometimes be influenced by the differences we've discussed. At any given moment, one developer may take the lead, while the other provides more passive, thoughtful input. This ranges from one developer shadowing and learning to providing context-aware input.
Development primarily involves thinking, designing, and decision-making rather than merely translating those concepts into a language the computer understands. With a focus on functionality rather than form, a second set of eyes can prevent time-consuming pitfalls such as analysis paralysis, nitpicking and excessive focus on coding details that add little to the conversation. Additionally, splitting research tasks between the pair can avoid downtime.
Async pair programming is also a viable option that can be highly effective when used across significant time zone differences. If your daily synchronization window is limited to 1-2 hours, you may encounter situations where decision-making drags on for days or even weeks. Through collaborative efforts, each pair member can cover gaps, enabling the other to catch up and resume work. This approach also offers the advantage of identifying issues early, reducing lengthy code review sessions, and minimizing upfront design work, particularly for proof of concepts.
Rotational pair programming offers its own benefits, which vary based on scope and area size. For an internal team, it increases resilience during crises by mitigating blind spots, thereby reducing the stress commonly associated with on-call duties. It also serves as a knowledge dissemination mechanism, distributing expertise so that most, if not all, team members can provide well-informed input, enhancing the team's appeal to external stakeholders.
When applied to a broader area, it can serve various purposes. It can help familiarize the team with external processes they rely upon or redistribute internal talent to areas within the organization where they may excel. Shadowing can also prevent expensive internal transfers by providing potential candidates with insights into the everyday tasks they would be expected to handle. If it’s not a good fit, it avoids setting an entire sequence of HR processes in motion.
As with all things in life, making well-considered decisions and applying them in moderation are key to success. Don't simply adopt this solely because it's trendy and everyone else is doing it, or view it as the new go-to pathway towards becoming SuperAgile.
It's beneficial to establish clear pairing objectives and outcomes from the start. However, it's crucial to recognize that some intangible effects may not be immediately noticeable or measurable: increased morale, burnout resistance, and enhanced problem-solving, to name just a few. Encouraging structured feedback and integrating it into retrospectives can enhance team awareness. Indirectly, you can quantify its impact by observing its effects on long-term code maintainability, code review, and quality control.
Unlock the Power of Different Perspectives
I finally discovered the true value of pair programming and its effectiveness in a recent, long-term project filled with uncertainty. Through fortunate circumstances we settled on a process that greatly improved efficiency when working collaboratively. Several substantial task overlaps made pairing seem like a natural choice, in part due to how impractical it would have been for multiple people to cover the same, vast amount of prerequisite material within a reasonable timeframe. On top of that, there were quite a few situations when subtle bugs or nuances in decision making would have been hard or nearly impossible to address in a timely manner when handled independently.
This highlights the importance of considering each case individually rather than applying prescriptive recipes blindly. At best, they serve as broad guidelines rather than rigid rules. It also becomes particularly evident when working with multi-cultural teams, dealing with a variety of differences. It's not sufficient to reduce them to a short list of checkboxes and call it a day.
It's not unusual for a single project to include teams located in various parts of Europe, both coasts of the United States, Asia, and sometimes Australia. Team location and members' cultural backgrounds impact various aspects such as openness to engagement and information sharing, feedback styles, work approaches and hierarchy views, values and priorities, self-perception, perceived stressors, and responses to them, among others. Seamless communication is always great, but most often than not, you should expect and account for a certain level of friction, regardless of how well intended everyone may be.
But wait, there’s more. The other significant factor is neurodiversity, with even conservative figures placing prevalence rates well into double digits, meaning you’re likely to encounter it, especially in self-selecting environments. Once again, it's crucial to remember that each individual is different, regardless of the broader groups they may belong to.
As a manager, you’re more likely to yield better results by inviting the possibility of pair programming than forcing it upon your team members. Otherwise, there's a real risk of performative actions and awkward displays, followed by concluding in disappointment that the new favorite toy is broken. This works because it helps to differentiate between cases where the limitations and reluctance is strongly ingrained in one’s personality or when it’s rather a result of unpleasant past experiences.
While some find pair-programming helpful and liberating, others may find it inhibiting. Just because it sounds and feels intuitive (a subjective notion), it doesn't mean it's suitable for everyone. Furthermore, while there's some correlation, don't expect an obvious split between extroverts and introverts. Again, I argue that preferences for or against are more related to perceived safety and personal experiences with vulnerability in the workplace than to robust neurological makeup.
This is particularly relevant during actual interactions, affecting aspects such as chemistry, flow, energy management, and compatible communication styles. Setting and maintaining reasonable boundaries and adapting the best tools for the job can significantly influence outcomes.
Take interviews centered around this type of interaction as they’re a distilled, high intensity representation of this work paradigm. By overlapping a clear power imbalance over an already high stress situation, the process becomes far more reliant on how invested each party is and how much of their personality and past they decide to bring into it. Things like a condescending tone, a lack of interest or attention, failures to notice non verbal cues or a susceptibility for going into one of the four major trauma responses can make or break the session.
The AI in pair programming
This leads us to consider the future where you may spend a significant amount of time collaborating with AI assistants through pair or mob programming. While you'll receive greater flexibility, many lessons transfer well, and there's a healthy balance of give and take.
It's a viable alternative in many ways, but it's far from perfect. Even disregarding glaring privacy and copyright concerns around black box solutions, you must still consider their limited capabilities, uncertainty, and unreliability in introducing subtle bugs, the risk of investing time in creating and refining prompts, and the possibility of not obtaining satisfactory results for further development. Especially when dealing with complex problems that extend beyond the AI's working context or training data.
Keeping expectations realistic is essential. Thinking AI assistants will perform complex reasoning or deep creative exploration may lead to disappointment for a few more years. They can mimic some abilities, particularly in commercial offerings and open-source models with complex enough internal architectures, especially when integrated into agentic systems simulating chain of thought and similar approaches. However, for smaller models, extensive hand-holding is often required, eventually relegating them to less demanding tasks like code completion.
At this point, don't expect an AI assistant to perform your job, as you likely wouldn't have one if it could. You can and should use AI assistants to quickly learn practical skills, particularly when experienced, and as a creative stimulus for bouncing ideas and sparking your own creativity. You can think of them as a journal who gives feedback, but closely monitor their tendency to mirror and reinforce your own thoughts.
This approach offers a "no wrong questions" mindset, which can sometimes help or hinder your ability to move quickly and experiment. Without judgment, you may feel liberated to ask many wrong questions before eventually asking the right ones and learn from both.
Whether you engage in pair-programming with a fellow team member or with a data system capable of acting like one, it still requires you to step outside of your comfort zone. It’s a good opportunity to reflect that sometimes growth happens when you embrace vulnerability no matter how uncomfortable it might seem. Nevertheless, your openness to collaborate and share space may positively influence more than just a fleeting moment of your professional journey.
Top comments (0)