Pair Programming Illuminated - Book Notes

Get Started. It's Free
or sign up with your email address
Rocket clouds
Pair Programming Illuminated - Book Notes by Mind Map: Pair Programming Illuminated - Book Notes

1. Introduction

1.1. Definitions

1.1.1. Pair Programming

1.1.1.1. a style of programming in which two programmers work side by side at one computer, continually collaborating on the same design, algorithm, code or test

1.1.2. Driver

1.1.2.1. One of the pair typing at the computer or writing down a design

1.1.3. Navigator

1.1.3.1. Other partner which has many jobs

1.1.3.1.1. observe the work of the driver looking for defects

1.1.3.1.2. Strategic thinker

1.1.4. Programming

1.1.4.1. design, development, debugging, testing etc

1.2. Why Pair?

1.2.1. Quality

1.2.1.1. pairs produce code with fewer defects

1.2.2. Time

1.2.2.1. pairs produce higher quality code in about half the time as individuals

1.2.3. Morale

1.2.3.1. pair programmers are happier programmers

1.2.3.2. helps job retention

1.2.4. Trust & Teamwork

1.2.4.1. pair programmers get to know their teammates much better

1.2.4.1.1. builds trust and improves teamwork

1.2.5. Knowledge Transfer

1.2.5.1. pair programmers know more about the overall system

1.2.6. Enhanced Learning

1.2.6.1. pairs continually learn by watching how their partners

1.2.6.1.1. approach a task

1.2.6.1.2. use language capabilities

1.2.6.1.3. use development tools

1.2.6.1.4. etc

1.3. History

1.3.1. 1953 - Fred Brooks, author of The Mythical Man Month

1.3.1.1. "Bill Wright and I first tried pair programming when I was a grad student. We produced 1500 lines of defect-free code; it ran correctly first try"

1.3.2. 1970's - Dick Gabriel, concieved Common Lisp and introduced patterns

1.3.2.1. reports pair programming in 1970s

1.3.3. 1980's - Larry Constantine, author of more than 150 technical articles and 16 books

1.3.3.1. observed "Dynamic Duos" producing code faster and more bug-free than ever before.

1.3.3.2. Concluded two programmers in tandem was not redundancy, but rather it was a direct route to greater efficiency and better quaity

1.3.4. 1995 - James Coplien of the Pasteur project at Bell Labs Research

1.3.4.1. Published the "Developing in Pairs" Organizational Pattern

1.3.5. 2000 - Kent Beck, developed Extreme Programming (XP) methodolgy

1.3.5.1. Largest known group of pair programmers following XP

2. 7 Myths of Pair Programming

2.1. It will double the workload with two doing the work one can do

2.1.1. reality - proved by a 16 week study at University of Utah

2.1.1.1. Get two people programming in pairs and they'll work more than twice as fast as one could have

2.1.1.2. majority of buggy production code comes from individually written code

2.2. I'll never get to work alone. I Couldn't stand that!

2.2.1. reality - based off of different surveys

2.2.1.1. ~30% spent working alone

2.2.1.2. ~50% spent pairing

2.2.1.3. ~20% spent working with more than 2

2.3. It will work well only with the right partner

2.3.1. reality

2.3.1.1. works well with most (though not all)

2.3.1.2. usually those with excess ego and/or a 'my way or the highway' attitude is the exception

2.4. Pair programming is good for training. But, once you know what you're doing, it is a waste of time

2.4.1. reality

2.4.1.1. two experts solving complex problems will come with a great solution, always better than what they would have come up with individually

2.4.1.2. two experienced programmers will fill many of each other's knowledge gaps

2.4.1.2.1. Everyone has gaps

2.5. I'll never get credit for doing anything. I'll have to share all the recognition with my partner

2.5.1. reality

2.5.1.1. pairing is about better quality code and better solutions for the project and benefits the team overall

2.5.1.1.1. so desired personal success transitions to desired team success.

2.5.1.1.2. individual success means nothing without team success (sports analogy)

2.5.1.2. Need to put effort into peer evaluations

2.5.1.2.1. valuable feedback to management and peers

2.6. the navigator finds only syntax mistakes. Compilers can do that better than humans can.

2.6.1. reality

2.6.1.1. Navigator is doing more than syntax checks

2.6.1.2. Navigator is holding the roadmap and is caught up with staying between the lines on a winding road

2.6.1.3. Overall design is constantly being assessed and re-considered by navigator while driver implements the latest agreed on idea

2.6.1.4. Also help brainstorm - brainstorming concludes good designs much faster than individual considerations

2.7. Only time I ever get any real work done is when I'm alone.

2.7.1. reality

2.7.1.1. This idea comes from a desire to be in the 'flow' or the zone

2.7.1.1.1. the zone is a mythical desired state that is actually not optimal

2.7.1.1.2. Losing context or flow can happen with a 15 second interruption

2.7.1.1.3. A pair will get interrupted less than someone working individually at their desk

3. 7 Synergistic Behaviours of Pair Programming

3.1. Pair Pressure

3.1.1. pair programmers put a positive form of pressure on each other.

3.1.1.1. Programmers admit to working harder and smarter on programs because they do not want to let their partner down

3.1.1.2. Improved adherence to procedures and team standards

3.2. Pair Negotiation

3.2.1. stemming from 'distributed cognition,' two pair programmers arrive at the best solution together

3.2.1.1. each brings his/her own set of skills, abilities and outlook

3.2.1.2. both share the same goal for completing the task

3.2.1.3. jointly approach a problem each with a suggested alternative for attacking it

3.2.1.4. must 'negotiate' how to approach the problem jointly

3.2.1.4.1. evaluate more alternatives than either one would have considered alone

3.2.1.5. efficiently determines which is the best plan of attack

3.2.1.6. 'high five' eachother for being so smart and kicking butt on the task

3.3. Pair Courage

3.3.1. tremendous courage builder, giving us confidence to do things we might be afraid to do alone or simply might avoid and never do

3.3.1.1. Teacher analogy

3.3.1.1.1. Teacher asks all students to do a task and ask their answers at the end, only a few will respond

3.3.1.1.2. Teacher asks all students to work with a pair, nearly every pair will respond at the end, they are much more confidant in their answer

3.3.2. Strength in numbers!

3.3.3. Courage to admit when we don't know something

3.3.3.1. individually we would muddle through problems on our own embarrassed to ask others questions

3.3.3.2. in a pair we are much more likely to ask for help

3.3.3.3. Study shows 42% of developers are inclined to work on problems alone

3.3.3.3.1. the more experience a developer has the more likely he or she is to ask for help

3.4. Pair Reviews

3.4.1. 4 eyes are better than 2

3.4.2. Studies show peer reviews find defects earlier and the earlier a defect is found the cheaper it is to fix

3.4.2.1. pairing gives you minute by minute peer review, best way to find all bugs as early as possible

3.5. Pair Debugging

3.5.1. It is a common and effective practice to explain a problem to an inanimate object like a teddy bear or a duck and in explaining we come to conclude our problems

3.5.1.1. amplify this when talking to another person. The back and fourth with a human can lead to solving hard problems quickly

3.6. Pair Learning

3.6.1. Knowledge is constantly being passed between partners

3.6.1.1. tool usage tips to programming language rules to design and programming idioms

3.7. Pair Trust

3.7.1. Pairing allows teammates to open up to each other's knowledge and experiences and to see tha tthe end result is far better than anything they could have developed on their own

4. Overcoming Management Resistance

4.1. "I have to pay two programmers to do the job 1 could do

4.1.1. Wrong

4.1.1.1. The pair will get tasks done faster and with considerable less bugs

4.1.1.1.1. 1 bug equates an unknown amount of future effort that is hard to estimate but is agreed it's always better to catch a bug earlier

4.2. What's In It For Me Goals

4.2.1. I want to complete my project on time with high-quality code

4.2.1.1. 1996 Hill Air Force Base Report

4.2.1.1.1. Study where projects were to be done in two-person teams where EVERYTHING was done as a pair

4.2.1.2. 1998 Temple University Professor Nosek Reported a study of 15 full time experience programmers

4.2.1.2.1. working for 45 minutes on challenging problems, 5 individuals, 10 as pairs (5 pairs)

4.2.1.3. 1999 Study by authors- University of Utah - 28 students in the Senior Software Engineering course

4.2.1.3.1. Even mix of experienced students, individuals and pairs with the same assignments (pairs having extra work outside of the study to keep fair workload)

4.2.1.4. Industry data reports that between 33 and 88 hours are spent on each defect found in the field

4.2.1.4.1. When each defect saved during code development can save defect correction time of between .5 and 88 hours pair programming quickly becomes the cost-saving and time-saving alternative

4.2.1.5. Time to market is often half the time with pair programming

4.2.2. I want to reduce my risk of losing a key person

4.2.2.1. Multiple people are familiar with nearly every part of a system leaving no key persons

4.2.2.2. Truck number is 2+ depending on frequency of pair rotation

4.2.3. I want my employees to be happy

4.2.3.1. Happier employees stay in their jobs longer

4.2.3.2. Turnover is costly

4.2.3.3. Based on 7 independent surveys of self-selected pair programmers, over 90% of pair programmers agreed that they enjoyed their jobs more when pair programming

4.2.3.3.1. 96% indicated that pair programming made them more confident

4.2.4. I want to reduce the amount of time it takes to train a new person

4.2.4.1. training costs are reduced which helps me manage my budget

4.2.4.2. New people can actually contribute to projects much earlier

4.2.4.3. Pairing is training on actual tasks while traditional training does not contribute toward the completion of the project

4.2.4.3.1. teaching by doing and not showing which has been proven to be more effective

4.2.5. I want my teams to work well together and to communicate more effectively and efficiently with each other

4.2.5.1. My team works together better because they know each other and like each other

4.2.5.1.1. makes happier employees and reduces information islands

4.2.5.2. Pairing encourages interteam communications

4.2.5.2.1. without pairing often individuals would show up put their headphones on, eat alone and go home

4.2.5.2.2. Over time teams get closer, eat together, often have personal friendships outside of work

4.2.5.2.3. Rapport and trust builds

5. Gaining Support & Acceptance from Peers

5.1. Cites Introducing Patterns into Organizations (2002)

5.1.1. Evangelist

5.1.1.1. Gradually introduce casual, noninvasive use of the practice with your peers

5.1.1.2. "Test the Waters"

5.1.1.2.1. Identify people that seem especially interested in new ideas - innovators

5.1.1.3. "Just Do It"

5.1.1.3.1. Don't label it as "Pair Programming" - this makes people anxious

5.1.1.4. Grow the pairs to other parts of the team forming the "Early Majority"

5.1.1.4.1. This can lead to a "Grass Roots" effort

5.1.2. Local Leader

5.1.2.1. After you have an Early Majority talk to your management and get him/her to be a local leader

5.1.2.2. Track statistics

5.1.2.2.1. # of bugs before and after

5.1.2.2.2. first hand experience and discussion of productivity of the team

5.1.2.2.3. test results that show quality is improving

5.1.3. Brown Bag

5.1.3.1. lunch or department meeting

5.1.3.2. increase involvement and information about pair programming

6. Transitioning to Pair Programming by Choice

6.1. Adopted more when developers

6.1.1. have increased choice in when to use that innovation

6.1.2. have decreased process control in how to use that innovation

6.1.2.1. Can't be told how exactly to do it

6.1.2.2. Can't be wild wild west, teams need some level of consistent organizational standards and procedures

6.1.3. their manager encouraged them to use the innovative technique

6.1.3.1. discourage "if you want to pair, go ahead and pair - I don't care" attitude

6.1.4. the innovation increases the predictability of their work

6.1.4.1. pairing results from University of Utah performed more consistently and predictably than individuals

6.2. manager introduction

6.2.1. Be the Local Leader and also the Evangelist

6.2.2. Ask a Respected Techie to read about pair programming

6.2.2.1. Let him/her try it

6.2.2.2. Don't rush this process

6.2.2.3. It is important for this person to genuinely be convinced of the technique through experience

6.2.2.3.1. If they are not, ask them to not publicly criticize and pick another Respected Techie

6.2.2.4. Encourage the Respected Techie to gain the support of other programmers

6.2.2.4.1. ask this group to organize a Pair Programming Tutorial

6.2.3. Organize an educational session for a larger organization

6.2.3.1. Run by the senior developers without management present

6.2.3.1.1. Should be prepared with a "Personal Touch"

6.2.3.1.2. bring up the negative things you have heard or anticipate audience bringing up

6.2.4. The Desired Accomplishments

6.2.4.1. Programmers who are interested in trying should sign up

6.2.4.1.1. team should develop an informal plan for who should try pairing with whom

6.2.4.2. Initial trial of technique should feel low risk for all invovled

6.2.4.3. Put in place a system of feeding back concerns and successes of these trials

6.2.4.3.1. can be as informal as stopping by senior programmers desk periodically

6.2.4.3.2. can be as formal as tracking progress / defects

6.2.4.4. Team should then discuss what would convince them that pair programming is or is not a valid technique

6.2.4.4.1. should decide what data they want to collect and how long it will take for them to decide on the validity of the technique

6.2.4.5. Team should discuss organizational guidelines for use of pairing

6.2.4.5.1. example

6.2.5. Involve Everyone

6.2.5.1. including skeptics

6.2.5.1.1. maybe pair an early adopter with a skeptic

6.3. Advice for Programmers

6.3.1. suspend disbelief and don't make threats

6.3.1.1. you never know what you might learn and too quick a reaction will make it all that much harder

6.3.1.2. form opinions after trying it for a couple of weeks

6.3.2. pretend it will work to give it a fair shot

7. Problem, Problems

7.1. Dependency

7.1.1. Becomes harder for developers to program alone

7.1.1.1. If you're alone, find another partner, or help be the second with someone else

7.1.2. They feel less confidant and can grow dependent of the partner

7.1.2.1. Always review what was done alone, with the pair, this will help keep things moving but still have confidant and allow for review and bug catching

7.2. Scheduling

7.2.1. Can be more difficult to schedule

7.2.1.1. Can be easy if always pairing with the same person

7.2.2. A lot of benefits to rotating pairs, so it needs to be managed

7.2.2.1. my ideas

7.2.2.1.1. Scrum bullpen environment

7.2.2.1.2. Meetings are often unnecessary - skip and continue to do work

7.3. The Ever-Popular Expert

7.3.1. Continuation of the scheduling problem

7.3.2. NOT a problem with scrum

7.3.3. GUI / Database / Kernal experts

7.3.3.1. Best to let them have time to work their critical tasks alone

7.3.3.2. potentially set up office hours

7.3.3.2.1. ( again, not a problem when using scrum )

7.4. Colocation

7.4.1. People come in to work at different times and have different schedules

7.4.2. Balance between the needs of the project and the needs of the employees

7.4.2.1. core pair programming hours

7.4.3. Remote workers - distributed pair programming

7.4.3.1. not as effective but it can be a valid option

7.5. Noise and Facility Considerations

7.5.1. requires a commitment from the organization in terms of facility changes.

7.5.2. more appropriate desk setups / cubicle space

7.6. Concentration

7.6.1. You can still work alone for a truly creative requirement and then come back together with a pair to discuss conclusions

7.6.1.1. Be open to revising your brainstormed-in-isolation solution

7.6.1.2. Most certainly, your partner can think of something you didn't think of when you were alone

7.7. Disagreements

7.7.1. Strategies for resolving conflicts

7.7.1.1. each of you go off alone for a specified period of time to cool off and investigate what you feel so strongly about

7.7.1.2. Take a walk around the building -- together!

7.8. Overconfidence

7.8.1. Sometimes a pair can feel they can do no wrong when working together

7.9. Rushing

7.9.1. Highly effective teams can sometimes feel a need to complete a task during a session.

7.9.1.1. Sometimes you need to not rush a solution and resolve it next session

7.10. Skill Imbalances

7.10.1. Pair new team members with mentoring types to keep them feeling welcome and limit frustrations

7.10.1.1. Mentor needs to give up control and allow the less skilled to drive most of the time

7.11. Simply Not for All

7.11.1. Might not work for someone

7.11.1.1. too introverted, soft spoken, or lacks confidence

7.11.1.1.1. Might grow into it with pairing of a great mentor or another very similar introvert

7.11.1.2. too self centred, egotistical or feels threatened

8. Workplace Layout

8.1. Basic Needs

8.1.1. sit comfortably side by side

8.1.2. both can completely view the monitors

8.2. Suggested Workplace Enhancements

8.2.1. Cave and Commons

8.2.1.1. Outer cubbies for devs to call home

8.2.1.1.1. may or may not have computers

8.2.1.1.2. a private space to decorate and take phone calls

8.2.1.2. primary focus is on pairing stations at tables in the center for the team to work together optimally

8.2.2. 1 Computer, 2 Displays, 2 Keyboards, 2 Mice

8.3. Interpair Communications

8.3.1. Pairs need to be able to hear others pairs on the team

8.3.2. There is a lot of benefits to overhearing other conversations to help each other out even when not directly communicating

8.4. Development Environment

8.4.1. Ideally there is a standardized enviornment

8.4.2. The team needs to agree to program in a different environment for at least half the time for the next 'n' weeks

8.4.2.1. 'n' doens't have to be too high before they decide they can converge on a single enviornment

9. Pair Rotation: Communication, Knowledge Management, and Training

9.1. Pair Rotation

9.1.1. Usually happens very casually without any formal schedule

9.1.1.1. Teams learn to choose the right partner for the right situation

9.1.2. Easiest to stomach and accomplish with small tasks (< week)

9.1.3. Partner Assignment

9.1.3.1. Daily Scrum a good time to identify when we can help each other and self identify to pair with someone

9.1.3.2. Just say yes strategy

9.1.3.2.1. When someone takes a task they ask someone to pair with them and said someone can't say no

9.2. Training

9.2.1. Pairing can reduce training time by a factor of two compared to not pairing

9.2.2. Split the team into 'Progress' team and 'Training' team

9.2.2.1. Training team is made of mentors and new team members

9.2.2.2. As team members pair and gain enough experience they transition to the progress team

10. Other Issues to Consider

10.1. Performance Appraisals

10.1.1. Companies often focus on individual performance

10.1.2. Switch to utilize peer evaluations

10.1.2.1. After all, who knows better?

10.1.2.2. Ask the employee for 3 names of who to have peer evaluate, and 3 names of who should NOT peer evaluate to give a guideline on personal conflicts

10.2. Team Size

10.2.1. keep it small (scrum team size applies)

10.2.2. Try to have even number teams =)

10.3. Quality Assurance

10.3.1. Pair Programming is another QA checkpoint which will reduce bugs and improve quality heavily

10.3.2. 'Formal Testing' time is often reduced due to all the benefits

10.3.3. Peer reviews also go smoother or become obsolete at times

10.4. Functional and System Testing

10.4.1. Encourage testing be a pairing activity as well

11. Tips and Tricks

11.1. Give the driver a few nanoseconds to find and correct his or her own mistakes

11.1.1. Same for navigating menus etc

11.2. If your partner is getting bored pass them the keyboard

11.2.1. If both of you are tired, get up and walk around or take a break

11.3. If your partner is getting tired or frustrated, grab the keyboard

11.4. Come to an understanding on how pairing will work with a new pair

11.4.1. Negotiate on what each person likes to do and how. What each does well etc

11.4.2. Takes < 5 min

11.5. Handling Conflict

11.5.1. Navigator record (on cards) contentious issues that are bothering the driver.

11.5.1.1. Review every half hour.

11.5.1.2. This allows progress to continue but concerns to be addressed before it becomes too late

11.5.2. Separate for a period of time ~ 10 min

11.5.2.1. investigate on their own, take a walk

11.5.2.2. get back together to discuss their investigation

11.5.3. Let the navigator drive for 5 minutes

11.5.3.1. If driver agrees, driver can finish it out, if not he can roll back

11.5.3.2. Sometimes just trying can make both sides see the good and bad and lead to an agreement

11.6. Use a coding standard

11.6.1. Eliminates partner disagreement due to style

11.7. Use test driven development

11.7.1. Helps facilitate switching between driver and navigator

11.8. Practice active listening

11.8.1. Acknowledge, restate, and summarize ideas

11.9. Talk a lot

11.9.1. Talk about what you're diong

11.9.2. Explain techniques for using the development enviornment

11.10. If your partner is not listening at all, get up and walk away

11.11. Just ask!

11.11.1. If you don't understand what your partner is doing, stop and ask

11.11.1.1. Still don't get it? Ask again!

11.11.2. It can be tough to learn to talk while driving, help each other out. We aren't keeping secrets we just forget how to share them

11.12. Take enough showers, eat lots of breath mints

12. Pair Programming Partner Picking Principles

12.1. Nonissue Dynamicis

12.1.1. Gender Nonissue

12.1.1.1. Issue

12.1.1.1.1. Gender is not an issue

12.1.1.2. What This is About

12.1.1.2.1. Partner Dynamics still apply but gender makes no difference to them

12.1.1.2.2. Communication is the key and men and women communicate differently

12.1.1.3. If There are Problelms

12.1.1.3.1. Usually is Gender Disrespect

12.1.2. Culture Nonissue

12.1.2.1. Issue

12.1.2.1.1. Having pairs w/ different cultural backgrounds is wonderful for building trust and communication

12.1.2.2. What This is About

12.1.2.2.1. Culture doesn't matter as long as they communicate

12.1.2.2.2. Actually pair programming w/ culturally diverse team can help everyone understand each other and gain trust

12.1.2.3. If There are Problems

12.1.2.3.1. Cultural bigotry can exist in either partner

12.2. Partner Dynamics

12.2.1. Definitions

12.2.1.1. Average Programmer

12.2.1.1.1. Lots of experience but just average

12.2.1.1.2. Little experience becoming an expert

12.2.1.2. Novice Proogrammer

12.2.1.2.1. Doesn't necessarily mean new dev but maybe just new to the team

12.2.2. Expert-Average Pairing

12.2.2.1. Intent

12.2.2.1.1. Accomplish average job

12.2.2.1.2. Raising the skill level of one pgorammer

12.2.2.2. Characteristics of Success

12.2.2.2.1. Not Average 1 programmer, but an Average 2 programmer

12.2.2.2.2. Expert does some mentoring

12.2.2.3. Challenges

12.2.2.3.1. Average programmer really is average

12.2.2.3.2. Average programmer does not interact enough w/ the expert

12.2.2.3.3. Average programmer doesn't seem to "get it"

12.2.3. Expert-Novice Pairing

12.2.3.1. Intent

12.2.3.1.1. Get easy jobs done well while training a novice programmer

12.2.3.2. Characteristics of Success

12.2.3.2.1. Novice learning by watching the expert

12.2.3.2.2. Novice helps the expert do a better job

12.2.3.3. Challenges

12.2.3.3.1. Teacher like qualities in expert required

12.2.3.3.2. Comfortable environment that is nonthreatening

12.2.3.3.3. Expert not open to listening to advice from apprentice

12.2.4. Novice-Novice Pairing

12.2.4.1. Intent

12.2.4.1.1. Produce production code in a relatively noncomplex area of the project giving valuable experience to both programmers

12.2.4.2. Characteristics of Success

12.2.4.2.1. Helping each other learn

12.2.4.2.2. Together are willing to get help and move forward

12.2.4.2.3. Coach, instructor or mentor available to answer questions and help guide the pair

12.2.4.2.4. Works best in a class/teaching enviornment

12.2.4.3. Challenges

12.2.4.3.1. Easy for the pair to go down the wrong path

12.2.5. Extrovert-Extrovert Pairing

12.2.5.1. Intent

12.2.5.1.1. After long, thoughtful, constructive discussions, an excellent creative solution is created

12.2.5.2. Characteristics of Success

12.2.5.2.1. Pairing is all about communication, typically extroverts are the best communicators

12.2.5.2.2. Will often openly question decisions

12.2.5.3. Challenges

12.2.5.3.1. Loud and full of laughter

12.2.6. Extrovert-Introvert Pairing

12.2.6.1. Intent

12.2.6.1.1. Allow each partner to draw on his or her strengths and to improve upon his or her weakness

12.2.6.2. Characteristics of Success

12.2.6.2.1. Pairing still works in these groups

12.2.6.2.2. Extrovert must consciously work not to talk all the time and to draw valuable information from their partner

12.2.6.2.3. Introverts must speak up when there is a problem or if they disagree or don't understand

12.2.6.3. Challenges

12.2.6.3.1. Each partner must give up a little from their personality

12.2.7. Introvert-Introvert Pairing

12.2.7.1. Intent

12.2.7.1.1. A silent intensity leads to rock-solid solutions

12.2.7.2. Characteristics of Success

12.2.7.2.1. Maintain a decent level of interaction

12.2.7.2.2. not a lot of verbal communication but other means of communication

12.2.7.3. Challenges

12.2.7.3.1. Introverts can be very poor communicators

12.2.7.3.2. Introverts like to work locked away in a cave, they will strongly resist pairing

12.3. Real Problems

12.3.1. Professional Driver Problem

12.3.1.1. Root Cause

12.3.1.1.1. Desire for power, lack of confidence in partner, navigators lack of confidence in himself

12.3.1.2. General Form

12.3.1.2.1. driver will not give up control of keyboard

12.3.1.2.2. Driver unwilling to listen very much to navigator

12.3.1.2.3. Navigator feels disjointed, out of the loop, unimportant

12.3.1.3. Refactored Solution

12.3.1.3.1. Train driver on the benefits of pairing

12.3.1.3.2. Professional navigators must force themselves to take control

12.3.2. My Partner is a Total Loser and Other Excess Ego Problems

12.3.2.1. Root Cause

12.3.2.1.1. Attitude problem, usually nothing to do w/ the partner

12.3.2.1.2. the person just feels that he or she is better than anyone else

12.3.2.2. General Form

12.3.2.2.1. Partners can't stand to pair with the person

12.3.2.2.2. Intimidates his partner

12.3.2.2.3. Cohesion of the entire team becomes at risk

12.3.2.3. Refactored Solution

12.3.2.3.1. Best solution: Fire this person

12.3.2.3.2. Get known good partners to pair with them and show they can be valuable

12.3.2.3.3. Counsel the person and get them to acknowledge the problem and attempt to keep the ego in check

12.3.3. My Partner is SO Smart and Other Too Little Ego Problems

12.3.3.1. Root Cause

12.3.3.1.1. someone simply has zero confidence in themselves and feels inadequate in accomplishing even basic tasks

12.3.3.2. General Form

12.3.3.2.1. readily apparent

12.3.3.2.2. Have techniques to hide it - quiet, return questions instead of answering

12.3.3.2.3. "flip the bozo bit"

12.3.3.3. Refactored Solution

12.3.3.3.1. Let those who lack confidence drive

12.3.3.3.2. Pair them with someone with good people skills

13. Moving Ahead and Going Beyond

13.1. Triplets

13.1.1. three very experienced, mature and responsible

13.1.2. complex problem that justifies 3 brains

13.1.3. Keyboard, white board, and thinking out loud

13.2. Multidisciplinary Pairs

13.2.1. UI specialist with developer

13.2.2. tester and developer

13.2.3. Customer and developer

13.3. Projection Screen

13.3.1. No longer constrained by the desk

13.3.2. Supportive of triplet programming

13.4. Distributed Pair Programming

13.4.1. Don't perform as well as face to face pairing

13.4.2. Needs periodic face to face pairing to get to know each other and keep up with how to work together

13.4.3. Requires more verbal communication than ever

13.4.4. Seeing each other (web cams) is important for communication

14. Seven Habits of Effective Pair Programmers

14.1. Take Breaks

14.1.1. Check emails, return phone calls, etc

14.2. Practice Humility

14.2.1. It's okay to not know something, admit it and start helping the team as best you can

14.2.2. We all make mistakes, let others help you fix them before they go to prod.

14.3. Be Confident / Be Receptive

14.3.1. No judging, no competing with each other.

14.3.2. Work Together

14.4. Communicate

14.4.1. 15 sec without talking is long, 30 sec is an eternity

14.4.2. Programmers are stereotyped as quiet, but really they like to talk about what they are interested in, like programming

14.4.3. This is not a force of extroverts, this is excelling at what they do and showing colleagues and being shown by colleagues

14.5. Listen

14.5.1. Listen to details and try to stop assuming

14.6. Be a Team Player

14.6.1. Your partners work == your work

14.6.2. Use the word "we" a lot

14.6.3. If you don't understand something, ask, you are responsible for all of this work too

14.7. Hone the Balance between Compromise and Standing Firm