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.