Cross-Experience Pairing, the Beginning
Who are we, and why are we writing on this topic?
Irina’s Story
My experience with cross skill pairing started when I joined the industry as a technology graduate. During the 12 months of the my training programme I worked in multiple teams, all of which used pair-programming primarily as a technique to bring new joiners up to speed with the technology stack. So, as a junior, I paired with senior developers on virtually every story.
Interestingly, most (if any) of my pairs had not practiced pair-programming in their daily work and working with me was, for many, the first exposure to pairing across skill levels. Having no framework to follow, we were largely guided by our instincts in conducting pairing sessions. It is through that experience I realised that technical expertise should not be the only consideration in forming pairs with disparate skill sets (which seemed to be the case in my organisation).
When I joined Nat’s team, I was happy to discover that developers did collaborate on tasks. They formed pairs naturally and made the pairing experience seem effortless, fluid and fun.
However, my sessions with my senior colleagues felt quite different to that between developers with similar levels of expertise.
I wasn’t learning as fast as I had hoped and I often felt frustrated, overwhelmed, disengaged and even insecure. Granted, a lot of these symptoms were a natural reaction to facing a steep learning curve. However, a few months into my role I repeatedly faced similar problems.
Selfishly motivated to improve my own learning and happiness, I began analysing the causes of challenges and frustrations experienced during pairing and searched for ways to eliminate them.
It quickly became apparent to me that pair-programming across skill is more complex than two developers sitting down by a computer, exchanging jokes and technical expertise.
In fact, a relationship between a junior and a senior has many aspects unique to the disparity of technical expertise.
Differences in both developers’ schedules, different levels of emotional maturity, tight deadlines, hierarchy, organisational structure, existing team culture, even the age gap between the junior and the senior — all these factors can impact the effectiveness of a pairing session.
I documented my observations and analysis in the academic paper ‘Pair-programming from a beginner’s perspective’, which sparked a lively discussion in the wider tech community. I have also had a good fortune to collaborate with Nat on designing and running a series of practical workshops, which explore and address dysfunctional collaboration between junior and senior developers.
Nat’s Story
For many years in my career, I worked with the same colleagues. We acted as a loose knit team, brought into companies to reengineer systems or build new ones. The “secret sauce” behind our success was actually not so secret: we followed the practices described in the the famous XP White Book and Alistair Cockburn’s Crystal Clear, automated build and deployment, and applied some other technical design practices shared among members of London’s eXtreme Tuesday Club and that Steve Freeman and I eventually documented in the book Growing Object-Oriented Software, Guided by Tests. We programmed in pairs more often than not.
Lately my career has taken on more leadership responsibilities, helping to building teams, not merely software systems. I assumed pair programming would be an ideal practice to spread knowledge and technique. After all, that’s what the literature said. But I did not find it straightforward at all.
I found there to be a big difference between pair programming with the programmers I had known for years and who had similar (or more) years of experience, although different specialisms, and when pair programming as a senior developer with junior developers on my team. The former was a seamless, fluid experience quite unlike what I read about pair programming in the literature. We didn’t follow explicit Navigator/Driver roles, nor use explicit rituals, such as “ping pong pairing” to hand off programming activities to one another. When pairing we’d learned intuitively when to step in and make suggestions, sit back and think, ask for clarification, grab a sketch pad and pencil or CRC cards, step away from the computer for a discussion around a whiteboard or over tea, or gently berate our pair (often me!) for hogging the keyboard.
But when I paired with junior developers, that didn’t happen. In hindsight it seems obvious: pair programming is a skill that has to be learned and practiced. But my pair programming with junior developers was a frustrating experience for both of us. It added to our stress, and bored the poor programmer who had to pair with me. It helped to use rituals like navigator/driver, strong pairing or ping-pong pairing. But it never felt satisfactory.
Luckily Irina joined my team. As a recent graduate, she felt that pairing with senior developers was unsatisfactory and she wanted to fix it! She wrote up her ideas as an academic paper. The discussions I had with Irina made me realise that, yes, I wasn’t very good at pairing with junior developers (and that fact is now immortalised in the scientific record!), but also that many of the difficulties we encountered were symptoms of underlying causes within the work environment, team, and the organisation.
What next?
We have been giving talks and facilitating workshops to explore the challenges with pairing across levels of skill and seniority, and share ways in which professional developers have solved these issues in their teams. The results have highlighted the importance of pairing senior and junior developers, but also the general lack of guidance as to how to best go about doing so.
In this blog, we will collect and document the common challenges, and the solutions people have found to work well.
