Pair Programming Done Right
PJ has been giving this talk since 2007, and picked it initially because other topics seemed to be covered/solved. PJ feels like he is one of few who likes pair programming. Paired in lots of roles - architect, documenting, analysis, proj management.
Why don't people enjoy pair programming: - Too slow - do more myself - Management - not paying 2 for 1 - Devs - boring to watch. Want to do. Better alone, like computers not people. - Ergonomic chairs not for sharing! - Need to trace code changes to 1 individual. - Don't want to be judged / self conscious.
Why PJ thinks it is great! - 2 heads better than 1 - idea injections, always better solution. - Code is always more stable/robust - end up refactoring less than when done alone. - Favorite reason - my job is more fun, despite introverted leanings. - Usually more tired at the end of the day. - Love my job... time flies. - Pair stopped me from getting lost in code... took breaks, engaged, mental breaks. - "Bus factor" - how many people in team are you dependent on. Significant IP / point of failure. Best mode of training I know.
Doing it right: - Personal cleanliness!!! Also health/germs. Address early and up front. - Pomodoro-book.com - commit early and often, 25min chunks. - If not on track, challenge - what would we need to do to be able. Facilities positive change. - TDD - Bob Martin says "you're not a professional dev if not doing TDD". Like double entry accounting. Basic checking we should be doing.
DHH (person) makes great apps, but very vocal around - TDD got in his way and thinks it is dead. Can't pair with same person all the time. Systematically rotate with everyone. Avoid chewy-seated partnerships... Solo getting the glory. Most common reason why people say they don't like it.
3 recommended styles:
1) ping pong. - A writes first broken tdd test. B writes enough code to pass test. Swap and so on. - Best when equally familiar with domain/skills.
2) ball & board - 1 person gets mouse (senior), 1 gets keyboard (junior). - Newbie learns by doing. - Painful and hard to get used to. - Newbie not allowed to use arrow keys, senior gives guidance. - Junior has to explain where they want to go, forces conversations and teaching.
3) Batting practice - Coach lobs an easy lob ball for you to swing and hit. - Senior/domain sme continues to write good small unit tests to guide junior person writing code.
Good tools out there for it.
Next step is mob programming!!!!! Overhead projector, 1 keyboard, team of 4 working together (pj's team just like that number). Jeffrey's team did in bigger numbers.
Found team satisfaction was better stakeholders just as happy.