Output from our workshop at Agile Cambridge 2017

In the workshop, participants observed and discussed pair programming scenarios of varying quality, played out between two (fictitious) developers: Sam, the senior, and Jo, the junior. We captured the audience’s observations and suggestions for improvement, and have grouped them into rough themes below. I’m sure we missed some — the discussion was lively and interesting points came up faster than we could write them down. If you recall anything we missed, please let us know in the comments.

Interpersonal Communication

In scenario 1:

• Sam was working by himself
• Sam seemed to have had a predefined solution before Jo joined him, which he proceeded to implement on his own
• Sam conducted a monologue with himself, no input from Jo
• Sam behaved condescendingly towards Jo
• Sam ignored Jo’s questions
• When Jo contributed, Sam deleted all of her code with disregard for her efforts
• Sam remained possessive of hardware throughout the session
• Sam got distracted by the phone call in the middle of the session
• Sam didn’t try to get to know Jo
• No way for Jo to contribute their own knowledge to the problem
• When pairing, developers should act as equals, but many things interfere with that.

In scenario 2:

• Back-seat driving: Sam was treating Jo like a keyboard. This is not how strong pairing is meant to work.
• Sam didn’t ask for Jo’s opinion on how to solve the problem

Suggestions:

• When discussing each another’s code, offer praise before offering critique.
• Avoid the use of negative language (“… but …”), and words that chip away at confidence, like ‘merely’, ‘just’, ‘as simple as’, ‘obviously’ etc.
• Test a candidate’s ability to pair (work with others) during the recruitment process [More applicable to senior candidates? –ed].

Explaining the Wider Context

• In the first two scenarios Sam gave no background to the problem at hand and the wider business and technical context.
• Scenario 3 was better, as more business and technical context was provided. Still, Sam could have given more context about the development processes that the organisation follows: how business needs get turned into development work, roles/responsibilities within and outside the team, related documentation, tracking and reporting tools, etc.
• Sam could improve by explaining context with concrete examples
• How to fight the “That’s how we’ve always done things” attitude? Junior programmers can contribute modern techniques and new ways of thinking about things.
• Sam didn’t take Jo to a meeting about the project, which would have given Jo some context about the problem at hand

Conflicting Demands and Incentives

• Management may not value teaching, or consider it part of a senior developer’s job.
• There could be misaligned incentives and priorities from different parts of the organisation. E.g. the business side value immediate delivery over everything; IT value developing their staff even if delivery is reduced in the short term.
• If a senior is a contractor, they might feel that they must earn their daily rate. Teaching might not be included in their contract.
• Personal vs team performance evaluation

Vulnerability

• Sam overtly displays their seniority, which implies that they might feel vulnerable.
• Sam might be worried about their skill level (impostor’s syndrome)
• Sam might want to make a strong first impression but in choosing to show off their technical expertise, they end up making a bad impression
• Sam might not be used to accepting feedback.
• Juniors don’t always have the confidence to challenge the senior
• Sam may be the Jo’s line manager, and so gets to evaluate Jo for pay rises, promotions, bonus, etc., so Jo is worried about looking bad in front of the Sam.

Teaching as a Skill

• Sam might dislike pairing with junior programmers because they do not know how to teach. Developers are rarely taught how to teach.
• Sam doesn’t remember what it took to learn what he knows at present
• Teaching/coaching is a skill that must be learned
• Sam coded in silence, did not explain his thought process
• Sam was not teaching Jo anything, e.g. what does Jo know that Sam doesn’t?
• Sam never asked Jo how they wanted to approach the learning/pairing session. Copying the way teaching was done in school — we are never taught to learn or taught to teach in school.
• Interrupting the session with a meeting is an indicative of poor time management
• In the first two scenarios, pairing was demotivating for Jo
• The way Sam was acting didn’t allow Jo to build up any intrinsic motivation to get involved and try to solve the problem
• Because Sam did not give enough technical and business context, when given the opportunity to make their own decisions, Jo was only given an opportunity to fail

Suggestions

• Set the structure of the pairing session beforehand. At the start, ask the junior how they want to structure the session. At the end, run a micro-retrospective on difficulties and successes.
• Block out time for pairing sessions in the calendar to ensure that they are not interrupted by meetings.
• Asking juniors’ opinion during the first session could put too much pressure on them, and may be more effective on subsequent sessions

Other

• The terms “senior” and “junior” are not helpful.