http://citconf.com/wiki/index.php?action=history&feed=atom&title=Pair_Programming_Done_Right 2026-04-04T11:13:24Z Revision history for this page on the wiki MediaWiki 1.35.11 http://citconf.com/wiki/index.php?title=Pair_Programming_Done_Right&diff=16298&oldid=prev 2016-08-09T00:13:14Z

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

Micko