As a developer, you might want to ask yourself why Pair Programming is something you should be bothered doing? "Jeff Langr suggests the following;":http://langrsoft.com/articles/pairing.shtml
* Awareness of other parts of the system
* Resume building
* Decreases time spent in review meetings
* Continuous education. As someone who thinks he is a pretty hot programmer, I still learn new things every day from even the most junior programmers.
* Provides the ability to move between teams. ("this team is boring," "I can't stand working with him," "that stuff they're doing looks cool."). Since this can be a benefit for management as well, they don't have to clamp down on their resources.
* More rapid learning as a new hire. You don't sit and read out-of-date manuals for a week, or worry that you're going to be fired because the system looks indecipherable.
If you want some out-of-date manuals to read, I have a couple lying around that I don't use anymore. Me, Im too busy Pair Programming to read em.
Here are some notes based on "Jay Fields article on Pair Programming":http://www.infoq.com/articles/adopting-pair-programming
h4. Goals
* team enjoys pairing
* more productive
* team building
* efficiency
* knowledge sharing
* better code quality
h4. Methods
* 60-95% of core working day
* no-one advocates 100%
* Only production code written by pairs (XP)
h4. Pairing Stations
* flat, long desks
* 2 ppl comfortably
* fast machine
* 2 x 24" or 2 x 30" monitors
* 2 keyboards & 2 mice
* uber chairs
* create an environment >= working on own computer
h4. Tools
* use best-of-breed tools (vi/textmate or whatever)
* iterate - find your sweet spot
* image for quick deployment
* re-image regularly
** encourage dev's to add tools to the image
h4. Pair Switching
* benefits
** shared expertise (tools/domain/patterns/testing etc)
** balance learning & mentoring
* min 1 day
* max 2 days
* alternatives
** once per iteration
** promiscuous pairing
h4. Driving
* Ping pong programming
* Mentor
** teach Learner to fish
* Learner
** take control
** discuss / understand / implement / learn
* m,l = l,m
** roles can swap!
h4. Anti-Patterns
* Uninterested Pair
** not talking.
* Distracted Pair
** Helping others
** Checking email
** ancillary tasks
* Spellchecking Pair
** Large experience gap
** time pressure
** 1 person reduced to spellchecking
** cannot bridge gap & deliver - split
h4. Dont pair when
* Some things can be better done on own E.g.
** Research
** Spiking
** Debugging (when large experience gap)
** Doco
** Admin chores
h4. Managing
* don't force to pair
* pair properly, see if they prefer
* opposing views ok
** but intra-team they should agree
