Pair programming Isn’t a Luxury - It’s How We Work

“Share your screen, let’s look at this together.” If you’ve worked with us before, you might have heard this phrase more than once. It’s a simple invitation, but there’s often a hesitation before the response, a kind of uncertain pause. “Do we really need to pair on this?”, isn’t always spoken, but rather implied. Of course there are people that jump right in, but for many, the idea of pair programming can feel like a costly luxury at best or, at worst, bring on a cold sweat.

What We Mean by Pair Programming

If you’re not familiar with pair programming, it’s essentially a collaborative approach to software development, where two engineers work together at one workstation, sharing a single coding environment. One person, the “driver,” writes the code while the other, the “navigator,” reviews each line, offers guidance, and helps solve problems in real-time. There are multiple pair programming approaches, which we won’t go into right now (but see here for more info).

Since superluminar is a remote-first company, all our pair programming happens remotely, often via screen-sharing with tools like Tuple. We pair program in two constellations: either with our customers or with our colleagues as co-pilots. This is something we do during customer engagements but also internally at superluminar. The specific style we use depends on the project and the people involved.

Maybe you’re already thinking it… “Two people doing one person’s job? Isn’t that a waste of money?” There’s a common misconception that pair programming simply doubles the cost for the same output but that’s not how we see it, and it’s certainly not how our customers experience it. When pair programming is used to transfer knowledge, accelerate onboarding, and build shared understanding, it creates value far beyond the lines of code written during the session. We’ll explain this in more detail throughout the post.

Why We Use Pair Programming in Customer Work

There’s no single reason why we pair, and no single benefit that always comes first. It really depends on the project, the people, and the goals. But across many different customer engagements, we’ve consistently seen a whole set of advantages show up when pair programming is part of the workflow.

It helps customers get up to speed faster, whether that’s learning how the codebase works, getting confident with AWS, or understanding decisions we’ve already made. That onboarding process overlaps naturally with knowledge transfer: pair programming makes it easy to explain as we go, rather than dumping everything at the end. This ties into our ethos that we work with our customers, not for them. We want to build shared understanding, not just build solutions and walk away.

We also see technical benefits: cleaner architecture, fewer bugs, and faster feedback loops. Working together on tricky code or infrastructure decisions tends to produce better results than working in isolation. We can challenge each other’s assumptions, catch edge cases early, and make sure we’re all on the same page.

And beyond that, pair programming - especially as remote-only consultants - helps with something less obvious but very real: staying connected. Whether we’re pair programming with clients or with fellow superluminaries, it’s one of the best ways to avoid that sense of social isolation that can creep into remote work.

Common Objections - and Our Responses

Most of the resistance we encounter to pair programming isn’t direct. Customers rarely say “pair programming doesn’t fit our culture” or “this is too expensive.” Instead, it often shows up in more subtle ways - like engineers needing to “quickly do something else” when pair programming is proposed, or clients asking whether our team could split up and work on multiple tracks independently.

This makes sense in the context of consulting. We’re usually brought in for a specific project, often with clear goals and tight timeframes. In that environment, it’s natural for clients to focus on perceived efficiency: if two people are available, why not put one on Task A and one on Task B?

Our answer is simple: pair programming isn’t a luxury - it’s one of the main ways we deliver value.

Pair programming leads to better handovers, faster knowledge transfer, and higher-quality outcomes. It helps client teams learn new tools and technologies as part of the process. And on top of that, it builds trust and collaboration, which are particularly essential for successful remote work. Pair programming might not always look like the fastest path forward on paper, but in practice it helps us move with more confidence, fewer regressions, and less context lost. It’s not about being rigid - it’s about being deliberate with how we work together.

When We Don’t Pair

To be clear, there are no specific tasks we refuse to pair on. We’ve done research spikes, documentation, and even exploratory infrastructure work in pairs. But there are times when it’s simply not feasible, or not the right fit for the moment.

Sometimes the reasons are practical - like sitting on a Deutsche Bahn train without a stable internet connection. Other times, they’re personal. Not everyone has the energy to pair every day. Especially in remote setups, where everything happens through a screen, it’s easy to end up with a social hangover - that feeling of being socially overstimulated and needing space to recharge or reflect. That’s entirely normal, and we respect it.

There are also contextual factors to consider. When engineers are completely new to AWS or the specific services involved, jumping straight into pair programming can backfire. It’s hard to follow along - let alone contribute - when you’re still trying to understand the basics. In these cases, it’s often better for the customer’s engineers to spend focused solo time learning, with us available for questions and guidance as needed.

And not everyone wants to pair - which is totally fair. It can feel intimidating to share a screen with someone more experienced, and no one enjoys the pressure of “driving” while being watched. We’ve all felt our IQ drop the moment we start a live session, and it doesn’t help that our keyboards suddenly behave like they’ve switched to Dvorak. We get it.

We try to stay sensitive to the dynamics, and use a bit of gut feeling to guide when to press pause or try a different approach. We might suggest pair programming for a specific task, reduce the session lengths or find asynchronous alternatives. In the end, pair programming is one of our core tools - but it’s not something we force into every situation.

Pair programming is powerful, but like any tool, knowing when not to use it is part of using it well.

Conclusion: Why We’ll Keep Doing It

We know that pair programming isn’t everyone’s default - especially in environments where solo development is the norm and efficiency is measured by the number of tasks split across the team. But we hope this post made it clearer why we continue to advocate for it in our work with customers.

We don’t push for pair programming out of habit or stubbornness. We do it because we’ve seen the value it creates: faster onboarding, better knowledge transfer, fewer bugs, and more resilient solutions. We also do it because we believe that working closely together - even through a screen - leads to better collaboration and stronger teams.

If you’ve worked with us before, we hope this explains why we often suggest pair programming, even if it’s new or unusual in your team’s culture. And if reading this inspires someone to try pair programming on their own, there are some great resources from Tuple to help you get started here

Maybe you’d like to go one step further, you can explore AWS through pairing programming with us! Leave us a message with our contact form, if you’ve got a specific AWS related project in mind, or just want to test the waters in the cloud with our support. We’d love to hear from you 🙂

Rebecca is a Cloud Consultant at superluminar. After a career change from neuropsychology, she works in IT and is passionate about automation and data engineering. You can find her here on LinkedIn.

With over a decade of hands-on AWS experience and certifications spanning Developer to Security Specialty, Robert works as a Cloud Consultant at superluminar. Here, he shares stories and insights from his work — from serious AWS challenges to playful experiments and everything in between.