Unwritten Manual for Pair Programming

Slide 1

Slide 1 text

unwritten manual of pair programming Lemi Orhan Ergin

Slide 2

Slide 2 text

What is the purpose of pair programming?

Slide 3

Slide 3 text

teaching domain mentorship showing code getting confirmation finding bugs

Slide 4

Slide 4 text

teaching domain mentorship showing code getting confirmation finding bugs

Slide 5

Slide 5 text

producing software

Slide 6

Slide 6 text

(all the other points are side-products) producing software high quality

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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 ﬁrst book devoted exclusively 2002 PAIR PROGRAMMING

Slide 9

Slide 9 text

Core Practice in Extreme Programming http://www.extremeprogramming.org/rules/pair.html PAIR PROGRAMMING

Slide 10

Slide 10 text

http://www.extremeprogramming.org/rules/pair.html

Slide 11

Slide 11 text

Social Skill PAIR PROGRAMMING it means it is not suitable for everyone

Slide 12

Slide 12 text

Social Skill http://ﬁrstround.com/review/Why-Every-Startup-Should-Pair-Program

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

PAIR PROGRAMMING 2 developers 1 machine 1 monitor 1 keyboard 1 mouse

Slide 17

Slide 17 text

Programming Designing Reading Thinking Searching Deciding Programming Designing Reading Thinking Searching Deciding

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

?DOES IT HOW SEEM

Slide 20

Slide 20 text

EASY SCARY ?AWKWARD MOTIVATING INTERESTING UNCOMFORTABLE

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

DRIVER Tactician Strategist NAVIGATOR

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

10 EASY

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

Agree on one tiny goal at a time 3 Deﬁne your checkpoints. Select minor goals.

Slide 31

Slide 31 text

Rely on your partner and support him 4

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

Sync up frequently 6 Ask for agreement Ask if you miss something

Slide 34

Slide 34 text

Take a moment to celebrate 7

Slide 35

Slide 35 text

Rotate pairs in every 90 minutes 8 Do not exceed 4-6 hours a day Understand not everything has to be paired

Slide 36

Slide 36 text

Criticize the practice 9 Do you do retrospectives?

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

10 EASY

Slide 39

Slide 39 text

Give breaks 1 Pair programming is an exthausting practive. Never exceed 50 mins. You can use pomodoro counters for 25 mins intervals.

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

Write tests, no matter what You can get the most out of pair programming if you write tests. Try to write tests ﬁrst and push yourself to do TDD. 3

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

Full day pairing is ok, but not sustainable You have to come to ofﬁce at the same time, go to lunch together, take breaks at the same time, leave the ofﬁce at the same time. 5

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

Recruit correct people 10 h!p://scholarworks.lib.csusb.edu/cgi/viewcontent.cgi?article=1305&context=ciima

Slide 49

Slide 49 text

Recruit correct people 10 h!p://scholarworks.lib.csusb.edu/cgi/viewcontent.cgi?article=1305&context=ciima

Slide 50

Slide 50 text

Do not fall into Anti-Pattern trap Know the ways how you can screw up pairing and do your best accordingly.

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

TYPES OF PAIRING

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

GIT-PONG PAIRING $ git remote add personA $ 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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

No content

Slide 59

Slide 59 text

ENJOY remember whatever you do do not forget to https://www.ﬂickr.com/photos/fraserspeirs/3394902061 Joe O'Brien and Jim Weirich while doing ruby code review

Slide 60

Slide 60 text

No content