
The 3 Principles You Need to Understand to Become an Effective Learner - simbyotic
http://superpoweredmemory.com/becoming-an-effective-leaner
======
warrenm
>"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...](https://antipaucity.com/2008/05/08/queuing-the-next-
generation/#.WZBo_NMrLgo)) - 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".

