Download as PDF, PPTX
Uploaded byLemi Orhan Ergin
Unwritten Manual for Pair Programming
This document discusses pair programming and provides guidance on how to effectively implement it. It begins by explaining the purpose of pair programming is to produce high quality software. It then discusses various pairing techniques like ping-pong pairing and mob programming. The document also identifies benefits like higher quality code and faster defect removal, as well as challenges like being tiring. Finally, it provides tips for making pairing work well such as starting with a defined task, switching roles frequently, and not forcing people who strongly dislike pairing.
More Related Content
Similar to Unwritten Manual for Pair Programming
Unwritten Manual for Pair Programming
- 1. unwritten manual of pairprogramming Lemi Orhan Ergin
- 2. What is the purpose ofpair programming?
- 3. teaching domain mentorship showing code gettingconfirmation finding bugs
- 4. teaching domain mentorship showing code gettingconfirmation finding bugs
- 5.
- 6. (all the otherpoints are side-products) producing software high quality
- 7. Test Driven Development BehaviorDriven 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, oneof 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 inExtreme Programming http://www.extremeprogramming.org/rules/pair.html PAIR PROGRAMMING
- 10.
- 11. Social Skill PAIR PROGRAMMING itmeans it is not suitable for everyone
- 12.
- 15. Pairing does notamplify 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 1machine 1 monitor 1 keyboard 1 mouse
- 17.
- 19.
- 20.
- 21. MANY PEOPLE HATEIT 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 todo Have desire Define coding standards Have experienced people Practice and be patient Inspect and adapt PRACTICE PROGRAMMING PAIR TO MAKE STEPS YOURINDISPENSABLE
- 23.
- 24. DRIVER TacticianStrategist NAVIGATOR Codes Thinks about howto code better Doesn’t dictate the code Programs out loud Thinks through problems Reviews code Does sanity testing Reads and checks
- 25. Besides, if peopleprogram 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 incode 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.
- 28. Select you pairwisely1 Don't force people who don't like each other to pair Two juniors might not be a good idea
- 29. Start with areasonably well- defined task before you sit down2 It's better if you do not need to investigate a lot how to program or which technologies to use
- 30. Agree on onetiny goal at a time3 Define your checkpoints. Select minor goals.
- 31. Rely on yourpartner and support him4
- 32. Talk a lot!5 Doesthat 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 frequently6Ask for agreement Ask if you miss something
- 34. Take a momentto celebrate7
- 35. Rotate pairs inevery 90 minutes8 Do not exceed 4-6 hours a day Understand not everything has to be paired
- 36. Criticize the practice9Do you do retrospectives?
- 37. Schedule the pairingsif 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.
- 39. Give breaks1 Pairprogramming is an exthausting practive. Never exceed 50 mins. You can use pomodoro counters for 25 mins intervals.
- 40. Switch the keyboard It'snot a mentorship program, it is a development practice. Give that f*ucking keyboard to your pair and switch the roles. 2
- 41. Write tests, nomatter 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 personaltime 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 pairingis 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 usedshortcuts, 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 worryabout 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 shouldbe 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 yourpair's opinion Pairing is a matter of attitude. Do not always tell what to do. Ask for suggestions and discuss together. 9
- 48.
- 49.
- 50. Do not fallinto 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 ANTIPATTERNS
- 52.
- 53. A writes anew 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 $ gitremote 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 Bwrites 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 anadvanced 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, multiplenavigators 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. ENJOYremember whatever you do donot forget to https://www.flickr.com/photos/fraserspeirs/3394902061 Joe O'Brien and Jim Weirich while doing ruby code review