PAIR PROGRAMMINGKlarna TLV

Uri NativApril 2015

CULTUREPair Programming is part of our ways-of-working here at Klarna TLV and it is part of our culture

HISTORYPairing started as a way to onboard new developers, but we’ve continued doing it since we thought it adds value to other coding tasks as well.

WHY?Over time, we gave very little thought to pairing. - Why are we doing it?- When should we pair?- Is it mandatory to pair?

WHY?3.5 years later we ran a survey, and created a small thinking group.

Here are the results…

SURVEYMost people enjoy pairingpeople feel that we do it a reasonable amount.Few feel confident that we do it ‘properly.’

SURVEYPeople consistently cited knowledge sharing and ‘having a different set of eyes’ as being great things about pairing.

SURVEYProblems with coordination & frequent context switching was a consistent complaint.

SURVEYSome people identified pairing as making them more focused while others felt that they would be more focused working more independently.

PROS

&

CONS

PROSHigher code qualityMore readable codeEncourage discussionKnowledge sharingCollaborative code ownershipTeaching toolFocus

CONSPeople not feeling independent or not feeling comfortable working aloneSlow development time

- Can the same task be done by a single person?

- What’s the cost of coordination overhead?

Being dumb together- Hard to question the decisions of the pair

from the outside

WORKING ALONE

On top of the cons of pairing, working alone has some value and sometimes advantages over pairing.

WORKING ALONE

Some developers just prefer working alone

- They find themselves more productive and focused

Some developers are more engaged with their task when they work alone

- they get bored quickly when they are not in the driver seat

WORKING ALONE

Some people find it hard to learn when there is a knowledge gap as you don’t want to slow down the fast developer

- People find it more comfortable to learn using trial-and-error when working alone

You feel more obliged to ask your team members for opinion

We need to acknowledge that pairing is very

SUBJECTIVEThe value of pairing and what people gain

out of it DIFFERS BETWEEN DEVELOPERS and DIFFERS BETWEEN PAIRS

Which tasks are good candidates for pairing?

#1

TEACHING

#2

NON-TRIVIAL

#1

TEACHING

Pairing can be a great tool to teach people new dev practices or a new technology.The mentor should be in the right state of mind - the goal is to teach rather than complete the task fast. In this aspect the word pairing is misused.

#2

NON TRIVIAL

Any non trivial task is a candidate for pairing. Especially design/infra problems.Risky - a task might not be complex, but another set of eyes is needed to reduce the risk.

Pair programming works best with a large uncertain search space of problems and solutions. The closer to a solved problem, the less it helps

-- Kent Beck

“”

COORDINATION can be a big overhead. Here are some tips:

COORDINATION

TIP# 1The pair should try to plan their day in advance

- is it appropriate that we pair together considering our schedule, should meetings be moved?

COORDINATION

TIP# 2Turn off disruptions

- treat it as a meeting

COORDINATION

TIP# 3Understand as a pair what is the goal of the pairing

- this should guide the pair on what they have to pair and on what parts they can work alone

COORDINATION

TIP# 4A “pairing task” doesn’t mean you have to pair 100% of your time

- when someone “leaves”, the other developer can continue on his own

- ideally before you depart, agree on the next steps

LEFT WITHOUT YOUR PAIR?Work on other "peripheral" tasks if you have any

- peer reviews, answering emails, prepare the demo, etc

Work on the less sensitive / more trivial parts of the task

- the parts in your task which are most similar to the scenarios we listed under "when not to pair"

LEFT WITHOUT YOUR PAIR?In case there are no such tasks or the current task is urgent enough - continue on your own and sync your pair when he/she is back.

WHO DECIDES WHEN TO PAIR?- is it the team or is it the developer who codes?

The developer who owns the task- Same answer to “have enough people reviewed my code?” “who

chooses the design?”

The team can recommend, but it is the developer who codes is the one who makes the call

CONCLUSIONS

#1We see the value in pairing and we see the value of working alone.

CONCLUSIONS

#2A teaching/mentoring pairing task should be treated differently than a get-things-done task.

CONCLUSIONS

#3Pairing is subjective, thus we should not force anyone to pair or not to pair.This is the developer’s call.

CONCLUSIONS

#4If you want to work alone - go ahead.If you want someone to join you - ask, and the team should comply.

HAPPY PAIRING!

Wolf Shadow (D3A_0781) image by Steve Harris - https://flic.kr/p/63JyxQ

Uri Nativ@unativ