3 ms·
Misko says that the productivity hit of pair programming in minimal because most programmers program only 10-25% of the time; the rest is spent reading email, g
by russell 17y ago
Misko says that the productivity hit of pair programming in minimal because most programmers program only 10-25% of the time; the rest is spent reading email, going to meetings, and the like. Huh? I thought we flattened the management hierarchy and instituted agile programming to get rid of that nonsense.
He gives an extended example where pair programming enabled a new hire to configure his work environment in a half day (plus Misko's half day). I have found that a well documented setup procedure enables a new hire to set up his environment in half a day without involving a senior programmer. The second example of walking the new programmer through his first bug fix seems quite reasonable, but that is not pair programming in the large.
The comments seemed to be divided into two groups: those who were doing pair programming and loved it and those who were skeptical but were not pair programming. I admit I am in the second group. I would be interested in the experience of HNers.
- babo 17y agoThere is a huge benefit of personal bootstrap over a well documented procedure: it's personal, a first step to build a good relationship and a great team.
- donaq 17y agoThat probably wouldn't work for me. I learn better by reading (good documentation; failing that, code) than by listening. Conversation can be erroneous, but code (even bad code) never lies. I think optimal learning methods differ from person to person.
- TheSOB88 17y agoBut code isn't setting you up, human-written documentation (or, in the case of the article, humans) are.