How Pair Programming Can Help You Code Faster, Cleaner, and with More Confidence. Presented to WordCamp Jackson 2017 by Andy Melichar.

1. How Pair Programming Can Help You Code Faster,
Cleaner, and with More Confidence
PRESENTED BY ANDY MELICHAR FOR WORDCAMP JACKSON 2017

2. FIRST THINGS FIRST
A LITTLE ABOUT ME…

3. I LOVE
KARAOKE.
If you love karaoke,
check out
@wckaraoke on
Twitter!!

4. Serial
Hobbyist
Current obsession: HAM Radio.
My callsign is KEØATA

5. Director of Web
Development
for A2 Hosting
 We love hosting WordPress
websites, and we spend a lot of
time on making WordPress
better for our customers!
 Ask me about Agile/Scrum!

6. In this talk
we’ll cover:
1. Getting to Know You (and My Team)
2. What is Pair Programming
3. Benefits of Pair Programming
4. How we do Pair Programming at A2 Hosting
5. Important Considerations
6. Q&A

7. Audience:
(who are you?)
1. Developers
2. Development Managers
3. Project/Product Managers

8. Critical Point
#1
 If you don’t think this is for
you, I won’t take offense to
you joining the other talk!
 The other talk going on
right now is “Grow Your
Reach Through Blogging”
by Patricia Robertson

9. Time to Fess
Up!
 Who has tried some form of Pair Programming
before?
 Who here has a coworker, friend, etc., who they
could potentially pair program with?
 Who works under the Agile/Scrum methodology?
 What brought you to this talk?

10. My Web
Development
Team
 Consists of 7 full-time developers
 Managed directly by me
 5 employees local, but still work from
home about 80% of the time
 2 employees 100% remote
 2 different time zones
 Work primarily on projects internal to
A2 Hosting
 5 Mac users and 1 on Linux Mint
 I’m a weirdo PC user

11. Flash back almost two years ago…
 We managed our projects under waterfall
 Individual Web Developers were in charge is singular projects and tasks
 Our project management was done in Redmine with tickets
 And lots and lots of Google Docs
 And a lot of stuff in our head
 Developers were working 14-hour days regularly trying to meet deadlines
 Needless to say they (we all) were a bit burnt out

12. We also had some major knowledge
silos…
Employee A Employee B Employee C
System A
System B
System C
System D
That fix they
did last year
that solved a
super critical
production issue
that is happening
right now and
nobody can
remember what
it was.

13. “Hey, I’ve got an idea…
LET’S TRY THIS PAIR PROGRAMMING THING AND SEE HOW IT GOES.”

14. Critical Point
#2
Listen to your team
and be willing to try
new things!

15. WHAT IS PAIR
PROGRAMMING?

17. The “Boring” Definition
 Pair programming is an agile software development technique in which
two programmers work together at one workstation. One, the driver,
writes code while the other, the observer or navigator, reviews each line of
code as it is typed in. The two programmers switch roles frequently.
 While reviewing, the observer also considers the "strategic" direction of
the work, coming up with ideas for improvements and likely future
problems to address. This frees the driver to focus all of his or her
attention on the "tactical" aspects of completing the current task, using the
observer as a safety net and guide.
 Source: https://en.wikipedia.org/wiki/Pair_programming

18. The “Not-so-Boring” Definition
 Programmer One to Programmer Two: “I’ve got your back.”
 Programmer Two to Programmer One: “Let’s DO THIS!!”
 A few hours later… “Hey, Andy! We’re done with everything you gave us
and we need some more tickets!”

19. WOW THAT SOUNDS
AMAZING
TELL ME MORE ABOUT THIS AMAZING OPPORTUNITY…

20. THE BENEFITS
OF PAIR
PROGRAMMING

21. In an un-official,
statistically inaccurate
2016 survey of five web
developers…
5 OUT OF 5 DEVELOPERS SAID IF WE EVER WENT BACK TO THE WAY IT WAS
BEFORE PAIR PROGRAMMING, THEY WOULD QUIT.

22. 5 out of 5, you say?
 Obviously this is my team of developers
 I, as their manager, was skeptical about pair
programming going into it
 As was the rest of management

23. What the Research
Shows…
HONESTLY, NOT MUCH.

24. Critical Point
#3
Whether or not pair programming works
or makes sense for you is going to
depend on a LOT of variables:
1. The willingness of your team and
management
2. The amount of time you can dedicate
to ramping up and figuring out the
workflow
3. Your team’s ability to give and accept
critique and feedback
4. The type of work you do – repetitive
work, for example, does NOT benefit
from pair programming

25. In Their Own Words…

26. “I never believed the claim that pair programming was more
productive than two developers working alone. It made no
sense to me. Surely there would be too much overhead in
coordinating with another person. Once we started pair
programming, it became apparent that it was true. You
work so much more efficiently and get stuck so much less
often, it really is more productive and results in higher code
quality.”
-Dave M.

27. “When working solo on a problem I was hesitant to ask
coworkers for input because context switching takes a
major toll on productivity. There has to be a really good
reason to interrupt someone else's work. When working
on a problem as a pair there is no context switching
and you are both invested in the outcome.”
- Peter S.

28. “There is much less ‘clever’ code because the partner
will be like, ‘umm, this is going to bite us.’”
- Steve P.

29. The developers like it… so what?
WHAT DOES MANAGEMENT HAVE TO SAY ABOUT IT?

30. Well, I’m here talking to you about it!
1. An astounding change in the morale of my team.
 Because they actually ARE a team now, instead of a bunch of cowboy coders
writing ugly spaghetti code
2. Code quality has gone through the roof, and continues to improve on a
sprint-by-sprint basis
3. Defects that make it into production are far fewer, and the ones that do
make it are usually solved much faster
4. I spend a lot less time micro-managing each of my team members and
chasing down project statuses
5. I can trust ANY team member to work on ANY system in our
infrastructure
6. Literal, no-kidding, DAY ONE productivity of new team members

31. DAY ONE Productivity? Really?
 I’ve brought four new developers onto the team since we began pair
programming
 Each one of them was able to dive right into our codebase and complete
tickets their first day
 Our ramp-up time for a new developer prior to pair programming was 3-6
months

32. Critical Point
#4 YMMV

34. We’ve all reached that point
of brain-on-fire, bang your
head against SOMETHING
frustration point with our
code.

35. With pair programming,
it’s MUCH harder to get
to that point, because
someone is already
there, helping you
through the difficulties of
your code.

37. OK ANDY, WE GET IT, YOU LIKE PAIR
PROGRAMMING…
MAYBE TELL US HOW THIS WORKS IN THE REAL WORLD?

38. How We
Pair Program
at A2 Hosting

39. High-Level
of Our
Workflow
 We work in 2-week sprint cycles
 The first and last day of the sprint are meeting days,
those who are local come into the office, those who
are remote are brought in on a video conference
 The entire rest of the 2 weeks (8 working days)
everyone works from home
 Each developer is (usually) paired with another
developer for the entire sprint
 We rotate pairs every sprint

40. Day-to-Day
Workflow
 Start the day with a quick all-team huddle
 After that, our pairs connect up to begin pair
programming, they stay paired for the entire day
 Obviously taking breaks occasionally for lunch and
such (the pairs each agree on their schedules)
 First and last half-hour of the day is housekeeping,
code reviews, water cooler time, etc.

41. Wikipedia says it’s two programmers in one
room… but your team is remote?
 With the magic of the interwebs, we create our own rooms
 We use Google Hangouts for an audio connection
 We use C9.io as our shared, web-based development environment

42. Our Tools/Stack
 Cloud9 for our IDE - https://c9.io/
 Google Hangouts for Chat – https://hangounts.google.com/
 Atlassian Stack – https://www.atalassian.com/
 Jira for Project Management
 Confluence for Documentation
 Fisheye for git Respository Management
 Crucible for Code Reviews
 Old-skool IRC for chatting
 All code is stored in git
 Self-hosted development server running LEMP

43. Development Server

44. Critical Point
#5
The only way pair
programming will work
is if you have the right
technology to support
it

45. We Have Some Agreements
 Established coding standards that every team member agrees to abide by
– and the team agrees to support each other in following those standards
 Pairs are encouraged to work on tickets that provide an opportunity for
the transfer of knowledge
 No “cowboy coding” – all coding is done in pairs
 Follow the process
 Everything goes through code review
 Don’t take things live after 4pm or on Fridays

46. Processes that Support Pair
Programming
 At the end of every sprint we do a sprint review with the stakeholders
 At the end of every sprint we do a retrospective
 We do peer-360 reviews at 90-days, and then every 6-months
 Tool: https://www.spidergap.com/
 Agile/Scrum project management

47. Critical Point
#6
Pair Programming is
NOT for everyone, and
that’s OK.

48. Hiring is a Whole New Game
 First 10 minutes of any interview, I explain our process and the team
 I give the prospective employee an “out”
 They interview with me first, and then AT LEAST two members of the dev
team
 First 90 days is critical to ensuring team cohesion and their ability to adopt
our processes
 Hire slow, fire fast

49. IMPORTANT
CONSIDERATIONS
SOME OF THIS WILL BE REVIEW. MAYBE ALL OF IT.

50. As it is with any
new workflow,
it’s going to take
some time to
iron out the
details.

51. Absolutely,
positively get
management
buy-in from the
very beginning.

52. Absolutely be
sure your team
is ready for what
it takes to pair
program.

53. Credit Where
Credit is Due
THE VAST MAJORITY OF THESE PROCESSES AND IDEAS HAVE COME
FROM MEMBERS OF MY TEAM, NOT ME

54. Critical Point
#7
Pair Programming benefits GREATLY from
a management style that empowers the
team to figure things out on their own
and self-manage
The upside of this is your team learns how
to self-manage, which empowers them to
make better decisions, which in turn helps
them to deliver a better product.

55. Having
the right
tools is
essential.

56. A Final Thought…
JUST TRY IT!

57. Q&A TIME!
I MIGHT HAVE SOME ANSWERS FOR YOU

58. THANK YOU!