Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Two heads are better than one

Two heads are better than one

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


Elle Meredith

July 26, 2017


  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