Roles in Pair-Programming Across Skill: Leader/Adopter Model

In previous posts we have written about experts’ inability to share tacit knowledge, a phenomenon known as expert-induced amnesia in the field of psychology. This affects the relationship dynamics in senior-junior pairs differently to senior-senior pairs, because the junior expects that the senior will explain their thought process while they work together.

The literature about pair programming usually describes the roles ‘played’ by developers pairing together with the ‘Driver/Navigator’ model. While it certainly helps to visualise the roles of and equally distribute active participation among developers with similar level of expertise, in my experience it doesn’t achieve the same results in the context of junior/senior pairs.

On the surface, it is of course, possible to pass the keyboard and in this way, ‘swap’ the roles, however, in practical terms, when the junior is in possession of the keyboard, most merely follow clear detailed instructions from the senior. When the senior controls the keyboard, the junior is often unable to give such instructions, and the senior then carries on solving the problem, but now in the role of a ‘driver’, perhaps, communicating less detail to their pair.

In my experience, the driver/navigator model doesn’t cater for junior/senior pairs for a number of reasons:

  • It sets the fast pace two senior developers would enjoy when working together, which the junior might not be comfortable with. This can baffle the junior and apply unnecessary pressure which could in turn, damage their self-esteem.
  • The junior often ends up playing the role of the ‘keyboard monkey’ — not an equal participant in the pairing game
  • To the wider team, driver/navigator model communicates a relationship of equal participation and progress, which might set higher expectations with regards to the learning progress made by the junior than the progress actually made.
  • It is then a matter of time before the junior is given responsibility to complete a technical story alone, which they most likely won’t have the skill to do.

Which leads to the question: what model does suit pairing across levels of expertise?

I have heard pairing across experience being described as teacher/student or mentor/mentee relationships and, while both models definitely describe some kind of knowledge-sharing technique, I don’t think either model quite fits.

I consider mentor/mentee relationship to be a consistent and infrequent long-term set of interactions initiated by the mentee, during which the mentor contributes their expertise. In this relationship, the roles rarely equalise over time, i.e. the mentor remains a mentor, and a mentee remains a mentee (although a mentee might be a mentor to others)

Teacher/student model implies a classroom-teaching style, with the teacher has a role of active participant by being the source of the knowledge, and the student having a more passive role of the recipient of knowledge shared.

Pair-programming however, is about equal participation, full stop. A description from states:

“A teacher/student relationship feels very different from two people working together as equals, even if one has significantly more experience”

Failing to find a suitable framework to accurately describe the dynamics of junior/senior pairing relationship, I am proposing my own, which I call Leader/Adopter model.

It suggests equal participation of both developers in the session, with the senior consciously accepting the role of a leader.

From the skill-set point of view, Leader/Adopter framework can be analysed (at a very high level) as follows:

  • The skillset of a leader should include both technical expertise and emotional maturity, one or the other alone is insufficient.
  • The skillset of the adopter is incomplete, hence the role. However, as the adopter absorbs (or adopts) increasingly more expertise from the leader, their knowledge and the ability to lead the pairing session grows, eventually approximating that of the leader.

To highlight promotion of equal participation by the Leader/Adopter model, let’s briefly bring up a metaphor of a parent teaching their child to ride a bike, which I described in Pair-Programming from a Beginner’s Perspective.

The parent (or a person) tasked with teaching are not only expected to be a confident cyclist themselves, they also have to be adequately articulate and patient to lead a child through the learning experience. Therefore, the most effective teaching method involves a parent and a child working together as equals.

Why is it important to fit pair-programming across skill into an accurate model? Having a clear understanding of the roles which can be realistically played by the junior and the senior developers when working together will allow me to analyse the needs of both developers during the session and explore optimal behaviours and tactics to meet them.

I will talk about the needs in the next post.