Difference between revisions of "Pair Programming"
| Line 14: | Line 14: | ||
The group is asked how often they pair. They are asked if they think they are good. 2/3 of the audience says they could do better. | The group is asked how often they pair. They are asked if they think they are good. 2/3 of the audience says they could do better. | ||
| + | |||
| + | Is there a strict definition of paired programming? | ||
| + | |||
| + | There is a book on PP. It is kind of old school and rather academic. There is a whole book on PP that introduced antipatterns into the industry. People tried and got turned off. | ||
| + | |||
| + | (a presentation is brought up) | ||
| + | |||
| + | Why don't people want to pair? | ||
| + | From Group: | ||
| + | 1) Hygiene | ||
| + | 2) It can be slow | ||
| + | 3) People don't want to learn | ||
| + | |||
| + | From Presentation: | ||
| + | 1) I can get more done myself | ||
| + | 2) Watching someone else type is boring | ||
| + | 3) Slackers get a place to hide | ||
| + | 4) I like computers, not people | ||
| + | 5) I don't work well with others | ||
| + | 6) Desk not big enough | ||
| + | 7) Everyone should be in their cubes so we can call them. | ||
| + | 8) Compliance requires changes be by one person. | ||
| + | |||
| + | The point is I've heard a lot of reasons. | ||
| + | |||
| + | Fear is understandable. Keyboardists are different. | ||
| + | |||
| + | Reasons TO do it: | ||
| + | |||
| + | 1) Two heads are better than one. When talking about how to solve a problem it is often found that problems are solved faster. Talking to someone else about it helps, even if it is a rubber duck. Generally people have learned to solve problems different ways. | ||
| + | |||
| + | Question: Are there guidelines? Different approaches may or may not be right. | ||
| + | |||
| + | (Let's come back to that) | ||
| + | |||
| + | 2) The solutions that we come up with are better. They tend to last longer and have fewer bugs. Errors are caught as they are being written. The cheapest time to fix a problem is when the problem was introduced. | ||
| + | |||
| + | Statement: A problem where people are looking at code at different times. | ||
| + | |||
| + | Question: If I understand correctly, the way to pair is to sit next to each other. Heavyweight and Lightweight? | ||
| + | |||
| + | (Let's come back to that) | ||
| + | |||
| + | 3) People are happy. My ease and joy at work is greatly improved when I do paired programming. I may be more tired at the end of the day because I paired all day but I am a much happier person and contributor when I have been in a social interaction session all day. | ||
Revision as of 07:39, 3 October 2015
Question: My team is half here and half in India.
A: Skype?
Sometimes the overlap is two time zones. You have a difference that is hard to overcome.
A: Teamwork work it out.
Stories should be split...
Inline QA can have a problem qa'ing two stories. That can be challenging.
The topic is restated. How to do paired programming well and pairing is caring is combined.
The group is asked how often they pair. They are asked if they think they are good. 2/3 of the audience says they could do better.
Is there a strict definition of paired programming?
There is a book on PP. It is kind of old school and rather academic. There is a whole book on PP that introduced antipatterns into the industry. People tried and got turned off.
(a presentation is brought up)
Why don't people want to pair? From Group: 1) Hygiene 2) It can be slow 3) People don't want to learn
From Presentation: 1) I can get more done myself 2) Watching someone else type is boring 3) Slackers get a place to hide 4) I like computers, not people 5) I don't work well with others 6) Desk not big enough 7) Everyone should be in their cubes so we can call them. 8) Compliance requires changes be by one person.
The point is I've heard a lot of reasons.
Fear is understandable. Keyboardists are different.
Reasons TO do it:
1) Two heads are better than one. When talking about how to solve a problem it is often found that problems are solved faster. Talking to someone else about it helps, even if it is a rubber duck. Generally people have learned to solve problems different ways.
Question: Are there guidelines? Different approaches may or may not be right.
(Let's come back to that)
2) The solutions that we come up with are better. They tend to last longer and have fewer bugs. Errors are caught as they are being written. The cheapest time to fix a problem is when the problem was introduced.
Statement: A problem where people are looking at code at different times.
Question: If I understand correctly, the way to pair is to sit next to each other. Heavyweight and Lightweight?
(Let's come back to that)
3) People are happy. My ease and joy at work is greatly improved when I do paired programming. I may be more tired at the end of the day because I paired all day but I am a much happier person and contributor when I have been in a social interaction session all day.
