Two heads are better than one

Learn how to pair effectively, considering the psychological mindset when pairing, pairing etiquette, techniques, ideal desk setup...

Transcript

1. T W O H E A D S A R E B E T T E R T H A N O N E E L L E M E R E D I T H » @ A E M E R E D I T H » B L A C K M I L L . C O
2. W H AT G E T ' S I N T H E WAY I S F E A R
3. C O N F I D E N T H U M I L I T Y – A N G E L A H A R M S
4. “It’s about… having the courage to say, “I don’t know what’s going on”. And so we need to do this again or figure it out or talk about it. Courage to grab the keyboard [or] give it up… whether you are junior or a senior, it’s your job to take the lead into teaching the other person how to collaborate because collaboration is a beautiful thing but most people don’t know how to do it.’’
5. Psychological safety is ‘‘a sense of confidence that the team will not embarrass, reject or punish someone for speaking up… It describes a team climate characterized by interpersonal trust and mutual respect in which people are comfortable being themselves.’’
6. B E N E F I T S • Improves code design quality • Reduces bugs • Enhances technical skills (become a better programmer) • Improves transfer of technical skills • Improves team communications • Improves diffusion of knowledge among the team • Reduces staffing risk • Improves focus
7. B E N E F I C I A L S K I L L S • Prefer talking over thinking • Listening • Being friendly • Being gentle • Being curious, not passive
8. T O M A K E Y O U R PA I R I N G S E S S I O N S U C C E S S F U L , F O C U S O N T H E C O D E
9. W H E N PA I R S A R E E N G A G E D , F U L LY C O L L A B O R AT I V E , N O T D I S T R A C T E D = > g o o d p a i r i n g s e s s i o n
10. B E F O R E H A N D • Establish a communication channel if remote pairing • Personal check-in • Work approach check-in • Agree on tools • Discuss Git workflow • Agree on technique • Communicate your expectations so that you’re on the same page
11. A F T E R WA R D • Hold a retrospective
12. PA I R I N G E T I Q U E T T E • Share everything equally: no keyboard hogging • Turn off notifications/close apps to remove distractions • No social surfing, checking Twitter, Facebook, or email • Stop when you’re tired - take many breaks • When you see someone make a typo, wait • When talking about code, always refer to line number and file name • When disagreeing, talk in terms of benefit • When you're the navigator, don't dictate the code
13. T E C H N I Q U E S • Driver-Navigator • Active participation and constant communication is crucial • Tip: switch roles throughout the session • Potential pitfall: navigator stops paying attention, and the driver starts doing their own thing
14. T E C H N I Q U E S • Ping pong • Especially effective when writing tests • Tip: control can be passed back and forth frequently ,but in order to target what each person needs in their learning, it requires communication • Potential pitfall: not setting expectations ahead of time could make it more difficult to decide who is doing what
15. T E C H N I Q U E S • Distributed Pairing (remote) • Tips: invest in a good headset; Become more comfortable with the tools; Be more vocal about when to switch driver and navigator roles • Potential pitfall: technical issues are common, so test your tools ahead of time!
16. I D E A L D E S K S E T U P • 2 monitors, 2 keyboards, 2 mice/trackpads, 1 computer • Lowest denominator text editor • Shared `.vimrc`
17. R E M O T E PA I R I N G T O O L S • tmate.io (+ Skype or Google Hangouts) • `brew install tmate` • `tmate` • `ctrl d` to stop session • Screen Hero
18. PA I R I N G W I T H J U N I O R S • Don't type • Let them make decisions and mistakes • Take breaks • Be prepared to say “I don’t know” • Find what they can teach you
19. PA I R I N G W I T H A R O C K S TA R As a junior you are still providing value and it is your job to teach them how to collaborate and communicate better. You should ask heaps of questions. You should ask to type.
20. C O M P R O M I S E D E X P E C TAT I O N S • Paired project fallacy • I’m not as good as my partner • Developer’s ego • Ego is what prevents us from asking for help, learning, and collaborating
21. B R O K E N E X P E C TAT I O N S • Check your reaction • Silence, avoidance, passive aggressive, sarcasm, anger, personal attacks, fundamental attribution error… • Humanise the situation: • Why did this happen? is there a deadline? How do I contribute to the problem? • Facilitate a conversation
22. TA K E A WAY S • Confident humility • Learn from each session • Take breaks • Talk a lot! even more when remote pairing • Pay attention • Switch roles often • Be complimentary • Whoever knows least should do most of the driving • Every session with a new person will be different • Pairing does not replace code reviews
23. R E S O U R C E S • https://devchat.tv/ruby-rogues/049-rr-agile-communication-with-angela- harms • https://www.agilealliance.org/glossary/pairing/ • http://www.pairprogramwith.me • https://content.pivotal.io/blog/pairing-like-a-pivot • https://www.devmynd.com/blog/2015-1-pairing-with-junior-developers/ • https://www.thoughtworks.com/insights/blog/pair-programming-hard- talk-your-team • Does Pair Programming have to suck? by Angela Harms, https:// www.youtube.com/watch?v=OQXEzwXtzJ8 • https://www.nytimes.com/2016/02/28/magazine/what-google-learned- from-its-quest-to-build-the-perfect-team.html?_r=0 • http://www.fatosmorina.com/ego-enemy-software-developers/
24. T H A N K S ! E L L E M E R E D I T H » @ A E M E R E D I T H » B L A C K M I L L . C O