As someone who’s spent countless hours in pair programming sessions, both as a participant and as a coach, I’ve witnessed the good, the bad, and the occasionally ugly sides of co-creation. While pair programming and mob programming can be incredibly powerful tools for knowledge sharing and code quality, they can also become surprisingly counterproductive when certain patterns emerge.

The Silent Drift

Picture this: You’re deep in a pairing session, working through a complex problem, when you notice your partner’s eyes glazing over as they check their phone. We’ve all been there, but this “silent drift” is perhaps the most insidious enemy of effective co-creation.

I once worked with a team where this had become so normalized that people would actually be on-call handling tickets during their pairing sessions. It’s not just about the immediate disruption; it’s about the message it sends: “This collaboration isn’t worth my full attention.”

The solution isn’t draconian rules about device usage. Instead, establish clear communication channels. If you need to check something urgent, simply say so: “Hey, I need two minutes to respond to an important email.” OR “I’m on call today and its busy, so probably better we do this tomorrow hen we have my full focus.” This transparency builds trust rather than eroding it.

The Keyboard Dictator

“Type ‘System dot out dot println.’ No, no – use the shortcut! Press Command-Shift-O…”

Sound familiar? Welcome to what I call the “Keyboard Dictator” syndrome. It’s particularly common when pairing involves developers of different experience levels, but it’s toxic regardless of the participants’ seniority.

This micro-management style doesn’t just slow things down; it actively prevents learning. It’s like trying to teach someone to ride a bike by controlling their handlebars remotely – they’ll never develop the intuition they need.

Instead, embrace the “Five Seconds Rule”: When you see your partner doing something you think is inefficient or incorrect, wait five seconds before speaking up. You’d be surprised how often they’re already on their way to a solution, just via a different path than you would have taken.

That being said though, if your goal is to teach someone keyboard shortcuts, being a keyboard dictator can be a good way to do it, so this antipattern can be used for good as well as evil.

The Eternal Marathon

I once encountered a team that prided itself on pairing “all day, every day.” They saw it as a badge of honor – until burnout started hitting their team like dominoes falling.

Pairing for eight hours straight isn’t just unsustainable; it’s mathematically impossible. Between meetings, emails, documentation, research, and basic human needs, forcing continuous pairing creates more stress than value.

The most effective teams I’ve worked with typically aim for 2-3 hours of pairing per day, with built-in breaks and solo time. This rhythm allows for both intense collaboration and necessary individual processing time.

The Keyboard Hoarder

We all know that developer who, consciously or not, maintains a death grip on the keyboard during pairing sessions. It’s often someone who’s incredibly skilled and efficient – which paradoxically makes the problem worse.

This pattern is particularly dangerous because it creates a passive observer rather than an active participant. The observer’s mind starts to wander, and suddenly you’ve lost all the benefits of having two brains on the problem.

Implement strict rotation patterns. Tools like mob timer can help, but even a simple agreement to switch roles every 25 minutes can make a huge difference.

If you are one of these incredibly skilled and efficient, try using the Keyboard Dictator Antipattern and teach the other guys on your team how to work as effectively as you, and you won’t get as frustrated, and the other people on your team will improve and everyone is happy.

The One True Way™ Syndrome

Perhaps the most dangerous pattern I’ve observed is the belief that there’s one “correct” way to do pair programming. I’ve seen teams tie themselves in knots trying to follow textbook definitions of driver-navigator patterns when their natural working style was completely different.

The truth is, effective co-creation is more art than science. What works brilliantly for one pair might be completely ineffective for another. The key is to focus on outcomes rather than process: Are both participants engaged? Is knowledge being shared? Is the code quality improving? What is the goal for this session?

The Path Forward

The most successful pairing sessions I’ve witnessed share a common thread: they’re built on a foundation of mutual respect and clear communication. When something isn’t working, participants feel safe to speak up and adjust their approach.

Rather than trying to avoid these patterns through rigid rules, build a culture where team members can openly discuss what’s working and what isn’t. Regular retrospectives focused specifically on pairing practices can be invaluable.

Remember, the goal of co-creation isn’t to follow a perfect process – it’s to build better software through collaboration. Sometimes that means typing together for hours, and sometimes it means giving each other space to think and process.

A Final Thought

The next time you find yourself in a pairing session, pay attention to these patterns. Are you drifting? Dictating? Hoarding the keyboard? The awareness itself is often enough to start shifting toward more effective collaboration.

After all, pair programming isn’t about being perfect – it’s about being better together than we are apart. And sometimes, knowing what not to do is just as important as knowing what to do.