Kent Beck
2004-11-08 17:32:28 UTC
Write all production programs with two people sitting at one machine.
Set up the machine so the partners can sit comfortably side-by-side.
Move the keyboard and mouse back and forth so you are comfortable while
you are typing. Pair programming is a dialog between two people
simultaneously programming (and analyzing and designing and testing) and
trying to program better.
Pair programmers:
* Keep each other on task.
* Brainstorm refinements to the system.
* Clarify ideas.
* Take initiative when their partner is stuck, thus lower frustration.
* Hold each other accountable to the team's practices.
Pairing doesn't mean that you can't think alone. People need both
companionship and privacy. If you need to work on an idea alone, go do
it. Then come back and check in with your team. You can even prototype
alone and still respect pairing. However, this is not an excuse to act
outside of the team. When you're done exploring bring the resulting
idea, not the code, back to the team. With a partner, you'll reimplement
it quickly. The results will be more widely understood, benefitting the
project as a whole.
Pair programming is tiring but satisfying. Most programmers can't take
more than five or six hours of pairing in a day. After a week like that,
they are ready for a relaxing weekend away from work. I keep a bottle of
water beside me while I pair. It's good for my health and I'm eventually
reminded to take a break. The breaks keep me fresh for the whole day.
Rotate pairs frequently. Some teams report good results obeying a timer
that tells them to shift partners every 60 minutes (every 30 minutes
when solving difficult problems). I don't think I'd like this, but I
haven't tried it. I like to program with someone new every couple of
hours, switching at natural breaks in development.
Pairing and Personal Space
An issue that has come up and requires comment is the close contact in
pair programming. Different individuals and cultures are comfortable
with different amounts of body space. Pairing with an Italian is
completely different than pairing with a Dane. If you aren't aware of
the difference it can be acutely uncomfortable. Personal space must be
respected for both parties to work well.
Personal hygiene and health are important issues when pairing. Cover
your mouth when you cough. Don't come to work when you are sick. Avoid
strong colognes that might affect your partner.
Working effectively together feels good. It may be a new experience in
the workplace for some. When programmers aren't emotionally mature
enough to separate approval from arousal, working with a person of the
opposite gender can bring up sexual feelings that are not in the best
interest of the team. If these feelings arise when pairing, stop pairing
with the person until you have taken responsibility for and dealt with
your feelings. Even if the feelings are mutual, acting on them will hurt
the team. If you want to have an intimate relationship, one of you
should leave the team so you can build a personal relationship in a
personal setting without confusing the team's communication with a
sexual subtext. Ideally, emotions at work will be about work.
It is important to respect individual differences when pairing. In
Figure 5 the man has moved closer to the woman than is comfortable for
her. Neither is making his or her best technical decisions at this
point, although they may be completely unaware of the source of their
discomfort.
Figure 5: Personal space and pairing
If you are uncomfortable pairing with someone on the team, talk about it
with someone safe; a respected team member, a manager, or someone in
human resources. If you aren't comfortable, the team isn't doing as well
as it could. And chances are others are uncomfortable too.
Set up the machine so the partners can sit comfortably side-by-side.
Move the keyboard and mouse back and forth so you are comfortable while
you are typing. Pair programming is a dialog between two people
simultaneously programming (and analyzing and designing and testing) and
trying to program better.
Pair programmers:
* Keep each other on task.
* Brainstorm refinements to the system.
* Clarify ideas.
* Take initiative when their partner is stuck, thus lower frustration.
* Hold each other accountable to the team's practices.
Pairing doesn't mean that you can't think alone. People need both
companionship and privacy. If you need to work on an idea alone, go do
it. Then come back and check in with your team. You can even prototype
alone and still respect pairing. However, this is not an excuse to act
outside of the team. When you're done exploring bring the resulting
idea, not the code, back to the team. With a partner, you'll reimplement
it quickly. The results will be more widely understood, benefitting the
project as a whole.
Pair programming is tiring but satisfying. Most programmers can't take
more than five or six hours of pairing in a day. After a week like that,
they are ready for a relaxing weekend away from work. I keep a bottle of
water beside me while I pair. It's good for my health and I'm eventually
reminded to take a break. The breaks keep me fresh for the whole day.
Rotate pairs frequently. Some teams report good results obeying a timer
that tells them to shift partners every 60 minutes (every 30 minutes
when solving difficult problems). I don't think I'd like this, but I
haven't tried it. I like to program with someone new every couple of
hours, switching at natural breaks in development.
Pairing and Personal Space
An issue that has come up and requires comment is the close contact in
pair programming. Different individuals and cultures are comfortable
with different amounts of body space. Pairing with an Italian is
completely different than pairing with a Dane. If you aren't aware of
the difference it can be acutely uncomfortable. Personal space must be
respected for both parties to work well.
Personal hygiene and health are important issues when pairing. Cover
your mouth when you cough. Don't come to work when you are sick. Avoid
strong colognes that might affect your partner.
Working effectively together feels good. It may be a new experience in
the workplace for some. When programmers aren't emotionally mature
enough to separate approval from arousal, working with a person of the
opposite gender can bring up sexual feelings that are not in the best
interest of the team. If these feelings arise when pairing, stop pairing
with the person until you have taken responsibility for and dealt with
your feelings. Even if the feelings are mutual, acting on them will hurt
the team. If you want to have an intimate relationship, one of you
should leave the team so you can build a personal relationship in a
personal setting without confusing the team's communication with a
sexual subtext. Ideally, emotions at work will be about work.
It is important to respect individual differences when pairing. In
Figure 5 the man has moved closer to the woman than is comfortable for
her. Neither is making his or her best technical decisions at this
point, although they may be completely unaware of the source of their
discomfort.
Figure 5: Personal space and pairing
If you are uncomfortable pairing with someone on the team, talk about it
with someone safe; a respected team member, a manager, or someone in
human resources. If you aren't comfortable, the team isn't doing as well
as it could. And chances are others are uncomfortable too.