>"Given any activity, it's inevitable that one individual is more suited to the purpose than the other. With a significant gap, I don't see how a pairing won't just become mentoring. While it's great that knowledge will be shared, I'm uncertain how we could prevent a significant productivity drop of the dominant partner."
Individual "productivity" - at the expense of the organization - is pointless.
Focusing on the individual too much puts certain folks into positions of "unfireability" - which means when they inevitably leave, they'll leave hole that'll take several people to fill (which they'll probably brag about at their next job, "yeah, my last company had to hire 3 people to do my job").
The lack of focus on mentoring (whether through "pair programming" or other avenues) in most businesses leads to major disruptions whenever "important" people are unavailable. I wrote about that aspect of career growth over 9 years ago (https://antipaucity.com/2008/05/08/queuing-the-next-generati...) - and, if anything, it's only become more true in the intervening near-decade: most companies continue to prevent (actively or inactively) "junior" folks ("junior" as in "not yet experienced in XZY" - which may, or may not, correlate to age) from becoming "senior" without making them do it all themselves.
By a "lines of code per hour" or other similar pointless metric, pair programming (and mentoring in general) is not "efficient". But by the metrics of "less buggy code written", "better understanding of the code by more people", "more resilient organization to personnel disruption", etc, pair programming and mentoring have payoffs that far outweigh any perceived, simplistic, selfish view of "but he could do it better by himself".
1 comment
[ 3.5 ms ] story [ 14.5 ms ] threadIndividual "productivity" - at the expense of the organization - is pointless.
Focusing on the individual too much puts certain folks into positions of "unfireability" - which means when they inevitably leave, they'll leave hole that'll take several people to fill (which they'll probably brag about at their next job, "yeah, my last company had to hire 3 people to do my job").
The lack of focus on mentoring (whether through "pair programming" or other avenues) in most businesses leads to major disruptions whenever "important" people are unavailable. I wrote about that aspect of career growth over 9 years ago (https://antipaucity.com/2008/05/08/queuing-the-next-generati...) - and, if anything, it's only become more true in the intervening near-decade: most companies continue to prevent (actively or inactively) "junior" folks ("junior" as in "not yet experienced in XZY" - which may, or may not, correlate to age) from becoming "senior" without making them do it all themselves.
By a "lines of code per hour" or other similar pointless metric, pair programming (and mentoring in general) is not "efficient". But by the metrics of "less buggy code written", "better understanding of the code by more people", "more resilient organization to personnel disruption", etc, pair programming and mentoring have payoffs that far outweigh any perceived, simplistic, selfish view of "but he could do it better by himself".