Pair Programming - the lightning talk


Published on

Lightning talk introduce pair programming at the company I work for based on information gleaned from RailsConf2014

Published in: Software, Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Pair Programming - the lightning talk

  1. 1. Pair Programming the lightning talk version Barry Jones
  2. 2. Disclaimer • The information contained within this presentation is largely regurgitated from more experienced presenters at RailsConf 2014 – Joe Moore, Pivotal Labs: I’ve Pair Programmed 27,000 hours. Ask me Anything! – Chuck Lauer Vose, New Relic: Building kick-ass internal education programs (for large and small budgets) – Also, lots of online materials • My total pairing experience is approximately 30 hours.
  3. 3. What is it? • Two people sitting at the same computer – One codes – The other watches them code – They both discuss the problem – They take turns doing the coding • Two people sharing a computer screen remotely
  4. 4. You might be doing it wrong if… • You think there is a “right way” to do pair programming • You think one person has to code test while, the other codes the application to pass the tests • You have to pair all the time! • You have a single “pair partner”
  5. 5. What’s the benefit? • Continuous education – Team learns from each other – You learn to work more efficiently by watching and other people’s workflow tricks – Highest common denominator knowledgebase • Avoid the “the person who knows that system is out today” syndrome • Much faster on-boarding of new hires • Better education for junior/senior pair teams • Team gets to know each other better through meaningful conversation • UX + Devs can pair on an interface implementation • Support + Devs can pair on a bug resolution • Less likely to get “stuck” on a problem resolution working together – If a team is “stuck” on a story, rotate a person out to avoid stagnation • Less likely to get distracted when two people are keeping each other on track • Less likely to make mistakes when somebody else is proofing your code as you write it
  6. 6. What are the challenges? • Can take a little getting used to • Personality conflicts: highly assertive + highly passive – Assertive / Senior person can end up keyboard hogging – Using some type of timer/chess clock to track how much time each person spent coding is a good check here • Not useful for small tasks generally – Unless in 100% pair environment • Developers using different editors may have issues with keyboard shortcut change up
  7. 7. Remote Pairing Screen Hero – Free, both users can control the screen, both users have their own mouse pointer, users don’t have to worry about screen size differences
  8. 8. In Practice Experience • In my 30 hours of pairing since April… – Mark B. • Learned how to work faster in RubyMine – Jason L. • Learned about frontend architecture – Robbie L. • Learned about API routing – Jason H. • Learned about testing workflow – Tyler S. • Learned a ton about Ember.js • In 30 hours of pairing time, I’ve been very impressed – Learned every time
  9. 9. Easiest way to get started? • Make a point to pair with somebody on your team for 2 hours per week. • Feel free to do more • Provides a solid baseline of trying it out without monopolizing your time
  10. 10. THANKS!