Pair Programming :: Blip 2014
•Download as PPTX, PDF•
0 likes•636 views
Pair programming involves two software developers working together at one workstation. One person acts as the driver who types code while the other is the navigator who reviews the code and provides suggestions. The roles are switched regularly throughout the pairing session. Benefits of pair programming include less bugs, increased engagement from team members, and knowledge sharing between developers with different experience levels. While it works best for some teams and tasks, pair programming should not be imposed and may not be suitable or scale for all projects.
Recommended
Recommended
More Related Content
Similar to Pair Programming :: Blip 2014
Similar to Pair Programming :: Blip 2014 (20)
More from Pedro Gustavo Torres
More from Pedro Gustavo Torres (20)
Recently uploaded
Recently uploaded (13)
Pair Programming :: Blip 2014
- 2. Who am I? @_pedro_torres | pedrogustavotorres.com Pedro Gustavo Torres
- 6. A little bit of background
- 7. What is Pair Programming? • code is produced by two people programming: – on one task – on one workstation • Two keyboards (optional) • Two mice (optional) • Two monitors mirroring (ideally)
- 8. Driver…
- 9. …navigator
- 10. Change roles multiple times a day
- 11. Change roles multiple times a day
- 12. Change roles multiple times a day
- 13. ¡Quiz time! In which scenarios are the developers properly pairing? A B C D
- 15. Setup #1
- 16. Setup #2
- 17. Setup #3
- 18. Setup #4
- 20. All the times in front of…
- 21. …except in…
- 22. …and in!
- 24. Task BTask B Task ATask A Rotation between pairs Monday Wednesday
- 25. Pair rotation lader Rachel Davies, Agile Coaching
- 28. …bus factor…
- 29. …beginners mind
- 33. …better integration of new team members…
- 34. …limit WIP…
- 35. … to skip code reviews?
- 37. Less bugs…
- 38. …more fun…
- 41. …less slacking…
- 42. …and comfort zone wise…
- 44. Two heads think better than one
- 46. “Common” habits…
- 47. …no music / social “stuff”
- 48. So is Pair Programming for everyone?
- 49. It should not be imposed
- 51. Remotely works?
- 53. What about size or length of tasks?
- 54. Is it €xp£n$ive?
- 55. Is it only for mature teams?
- 56. Does it scale?
- 57. Companies that use it?
- 58. Scholars and hands-on fans?
- 60. Maybe slow…
- 61. …or all in!
- 62. Thank you Next time I’ll pair present!
Editor's Notes
- NCIS 2 IDIOTS 1 KEYBOARD video
- eXtreme Programming (XP) Software development methodology
- code is produced by two people programming: on one task on one workstation Two keyboards (optional) Two mice (optional) Two monitors mirroring (ideally)
- How should the driver and navigator seat? Which hardware should they have to pair programme effectively?
- All the times: In front of a working station Except in: meetings (finishing each other sentences) Bathroom (taking a leak)
- Collective code ownership… everybody gets a chance to know and “own” all the code Bus factor Beginners mind
- Collective code ownership… everybody gets a chance to know and “own” all the code Bus factor Beginners mind
- Engagement / Commitment Valuable Stand ups Better integration of new team members
- Should I stay or should I go? It really depends how obsessed you are with reviews…but I would say no. One of the members of the pair is already reviewing With proper rotation everybody gets a chance to review the code
- Less bugs More fun Less distractions Less interruptions from “outsiders” (changed from stopping one dev to stopping two) Less slacking on important stuff (testing, coding properly, adding comments, etc...)
- Because you are pairing: you have better ideas stay in the zone for longer More courage to take “risky”/”unconfortable” tasks Opportunity to learn and to teach
- [Image] Dude coding and listening to music [Image] Dude coding on workstation and having facebook on the laptop
- No music (at least headphones) No youtube No facebook No twitter No instagram No tumblr … Basically No social crap (your manager is going to love this part)
- * Nop! * You must: Be willing to give it a try Be social Be confident Embrace/deal with partners feedback Manage conflict Accept differences (not everything will be like you want) * It’s quite exausting It’s not rainbows and unicorns You will have a learning curve ahead
- BUT... It should be highly recommended! (Story at sky where the team stick to pp because of not wanting to do code review.)
- The non believers think so: Twice the salary / cost? Half the speed? So what about: Bugs? Technical debt? Bus factor? Team spirit? Morale? WIP limit? It wont be expensive on the mid/long term
- BSkyB 2degrees network NotOnTheHighStreet.com Virgin Media Orange O2 eBay Hashrocket Pivotal Labs Facebook Square Twitter Groupon SaludOnNet Feelunique.com CustoJusto.pt
- * Couple of days a week * Just one team * Just one pair (in a team) …