Pair programming has been part of the culture at Klarna TLV since onboarding new developers. A recent survey found that most developers enjoy pairing and knowledge sharing, but some find frequent context switching problematic. While pairing ensures higher code quality and knowledge sharing, it can reduce individual focus and slow development. The document concludes that pairing is subjective and best for teaching, non-trivial tasks, and reducing risk. Developers should choose when to pair or work alone based on task needs.

1. PAIR PROGRAMMING
Klarna TLV
Uri Nativ
April 2015

2. CULTURE
Pair Programming is part of
our ways-of-working here
at Klarna TLV and it is part
of our culture

3. HISTORY
Pairing 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.

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

5. WHY?
3.5 years later we ran a
survey, and created a small
thinking group.
Here are the results…

6. SURVEY
Most people enjoy pairing
people feel that we do it a
reasonable amount.
Few feel confident that we
do it ‘properly.’

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

8. SURVEY
Problems with coordination
& frequent context
switching was a consistent
complaint.

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

10. PROS
&
CONS

11. PROS
Higher code quality
More readable code
Encourage discussion
Knowledge sharing
Collaborative code ownership
Teaching tool
Focus

12. CONS
People not feeling
independent or not feeling
comfortable working alone
Slow 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

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

14. 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

15. 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

16. We need to acknowledge that pairing is very
SUBJECTIVE
The value of pairing and what people gain
out of it DIFFERS BETWEEN
DEVELOPERS and DIFFERS BETWEEN
PAIRS

17. Which tasks are good
candidates for pairing?
#1
TEACHING
#2
NON-TRIVIAL

18. #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.

19. #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.

20. 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
“
”

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

22. COORDINATION
TIP# 1 The pair should try to plan
their day in advance
- is it appropriate that we pair together
considering our schedule, should meetings
be moved?

23. COORDINATION
TIP# 2 Turn off disruptions
- treat it as a meeting

24. COORDINATION
TIP# 3 Understand 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

25. COORDINATION
TIP# 4 A “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

26. 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"

27. 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.

28. 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

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

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

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

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

33. HAPPY
PAIRING!
Wolf Shadow (D3A_0781) image by Steve Harris - https://flic.kr/p/63JyxQ
Uri Nativ
@unativ