pair programming at klarna tel aviv
TRANSCRIPT
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?
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.
SURVEYSome people identified pairing as making them more focused while others felt that they would be more focused working more independently.
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
#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
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# 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
#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.