Unwritten Manual for Pair Programming

This is the slide desk I delivered at meetups.

Transcript

1. unwritten manual of pair programming Lemi Orhan Ergin
2. What is the purpose of pair programming?
3. teaching domain mentorship showing code getting confirmation finding bugs
4. teaching domain mentorship showing code getting confirmation finding bugs
5. producing software
6. (all the other points are side-products) producing software high quality
7. Test Driven Development Behavior Driven Development Acceptance Testing Unit Testing Continuous Integration Continuous Delivery Emergent Simple Design Code Review Design Patterns Clean Code Principles Coding Standards SOLID Principles Continuous Deployment Enterprise Environments Version Control Systems PAIR PROGRAMMING a practice in development
8. P.J. Plauger, one of the implementors of C: "At each terminal were two programmers! Of course, only one programmer was actually cutting code at each keyboard, but the others were peering over their shoulders.” 1978-1988 1995 “Developing in Pairs” pattern in Jim Complien's book "Pair Programming Illuminated", by Laurie Williams and Robert Kessler, is the first book devoted exclusively 2002 PAIR PROGRAMMING
9. Core Practice in Extreme Programming http://www.extremeprogramming.org/rules/pair.html PAIR PROGRAMMING
10. http://www.extremeprogramming.org/rules/pair.html
11. Social Skill PAIR PROGRAMMING it means it is not suitable for everyone
12. Social Skill http://firstround.com/review/Why-Every-Startup-Should-Pair-Program
15. Pairing does not amplify my productivity. Instead, it erases all the bad habits I have that keep me from being a superstar on my own. h!p://www.sarahmei.com/blog/201%4/14/thoughts-on-two-months-of-pairing
16. PAIR PROGRAMMING 2 developers 1 machine 1 monitor 1 keyboard 1 mouse
17. Programming Designing Reading Thinking Searching Deciding Programming Designing Reading Thinking Searching Deciding
19. ?DOES IT HOW SEEM
20. EASY SCARY ?AWKWARD MOTIVATING INTERESTING UNCOMFORTABLE
21. MANY PEOPLE HATE IT So that's why I don't like pair programming. My weaknesses are exaggerated and my strengths are vetoed. For me, pairing doesn't work. For plenty of others, it very clearly does work. But not me. And that's why I quit the best company I've ever worked for: Pivotal Labs. h!p://mwilden.blogspot.com.tr/2009/11/why-i-dont-like-pair-programming-and.html
22. Learn how to do Have desire Define coding standards Have experienced people Practice and be patient Inspect and adapt PRACTICE PROGRAMMING PAIR TO MAKE STEPS YOUR INDISPENSABLE
23. DRIVER Tactician Strategist NAVIGATOR
24. DRIVER Tactician Strategist NAVIGATOR Codes Thinks about 
 how to code better Doesn’t dictate the code Programs out loud Thinks through problems Reviews code Does sanity testing Reads and checks
25. Besides, if people program solo, they are more likely to make mistakes, more likely to over design, and more likely drop the other practices, particularly under pressure. XP Explained
26. Higher quality in code Higher morale Better collaboration Shared knowledge Quicker to market Automatic code review Useful for training people Lower defect rates Faster defect removal Cannot force people Tiring Hard to setup common infra Hard to keep focus Clash of egos Harder for introverts No multiple committers Easy to do anti-patterns More effort on first & last sprint BENEFITS CAVEATS
27. 10 EASY
28. Select you pair wisely 1 Don't force people who don't like each other to pair Two juniors might not be a good idea
29. Start with a reasonably well- defined task before you sit down 2 It's better if you do not need to investigate a lot how to program or which technologies to use
30. Agree on one tiny goal at a time 3 Define your checkpoints. Select minor goals.
31. Rely on your partner and support him 4
32. Talk a lot! 5 Does that look correct to you? Do you think this is a valid test? What’s next? Trust me! Do you have any better idea? I suggest better names for variables and classes I suggest to implement in smaller steps I suggest possible inputs that we haven’t covered Let me give you some details about this technology Think out loud
33. Sync up frequently 6 Ask for agreement Ask if you miss something
34. Take a moment to celebrate 7
35. Rotate pairs in every 90 minutes 8 Do not exceed 4-6 hours a day Understand not everything has to be paired
36. Criticize the practice 9 Do you do retrospectives?
37. Schedule the pairings if required Pairing full time is not practical 25% for 3 days in a week 50% for 2 days in a week Revisit how you pair after sprints Talk on pairing schedules daily 10
38. 10 EASY
39. Give breaks 1 Pair programming is an exthausting practive. Never exceed 50 mins. You can use pomodoro counters for 25 mins intervals.
40. Switch the keyboard It's not a mentorship program, it is a development practice. Give that f*ucking keyboard to your pair and switch the roles. 2
41. Write tests, no matter what You can get the most out of pair programming if you write tests. Try to write tests first and push yourself to do TDD. 3
42. Take your personal time You need to read more, practice more, investigate more, learn more. Take your time for working alone at least few hours a day. 4
43. Full day pairing is ok, but not sustainable You have to come to office at the same time, go to lunch together, take breaks at the same time, leave the office at the same time. 5
44. Ask for used shortcuts, and learn Learn all the tricks and shortcuts your pair uses. If you notice your pair goes fast, stop him/her and ask the trick. 6
45. Do not worry about silly mistakes Hey you know that. It is normal to do silly mistakes. Relax. If your pair makes you stressed, let him/her know! 7
46. No one should be forced to pair However if pair programming is a core practice in your company, you might have to spend a lot of time with pairing. 8
47. Ask for your pair's opinion Pairing is a matter of attitude. Do not always tell what to do. Ask for suggestions and discuss together. 9
48. Recruit correct people 10 h!p://scholarworks.lib.csusb.edu/cgi/viewcontent.cgi?article=1305&context=ciima
49. Recruit correct people 10 h!p://scholarworks.lib.csusb.edu/cgi/viewcontent.cgi?article=1305&context=ciima
50. Do not fall into Anti-Pattern trap Know the ways how you can screw up pairing and do your best accordingly.
51. Superman
 I am fast, give me keyboard Absent-Mind Ed
 I am too distracted The Back-Seat Driver
 Tons of non-trivial comments The King of Shortcuts
 Navigator knows all shortcuts and pushes to use Fearful Freddie
 Refusing to refactor code that you didn't write The Anti-Mentor
 Leaving the newbie alone while pairing The Soloist
 Works solo as much as possible The Defactorator
 Revert all refactorings the others did ANTI PATTERNS
52. TYPES OF PAIRING
53. A writes a new test and sees that it fails
 B implements the code to pass the test
 B writes the next test
 A implements it
 And so on
 Refactoring is done whenever needed PING-PONG PAIRING Well suited for applying TDD If you aim to do remote pair programming, start with ping-pong
54. GIT-PONG PAIRING $ git remote add personA <URL> $ git fetch personA $ git checkout personA/master $ git checkout -b feature/PA-231 add your changes and commit $ git push personA feature/PA-231 A B $ git checkout feature/PA-231 add your changes and commit $ git pull personA feature/PA-231
55. A writes test B writes production code Repeat for 4-5 times A refactors all Switch roles MICRO PAIRING Similar to ping-pong, but you may pass a succeeding test and switch the keyboard
56. It is an advanced skill, best suited for seasoned, well-practiced teams Any number of pairs might work on a task at various times until it is complete PROMISCUOUS PAIRING A does pair programming with B B does pair programming with C C does pair programming with D on the same task even on the same day
57. 1 driver, multiple navigators Big projector or big TVs Switch every 15 minutes MOB PROGRAMMING The whole team works on the same thing, at the same time, in the same space, and at the same computer
59. ENJOY remember whatever you do do not forget to https://www.flickr.com/photos/fraserspeirs/3394902061 Joe O'Brien and Jim Weirich while doing ruby code review