In the past year I’ve realised that learning is a key aspect to developing and staying in touch with what is current. Essentially, there are two ways of doing this:

1) Adapted learning: This is when some members of your team have acquired a skill which is used in the currently project. You see how it is being used, and try to catch on and try to mimic the usages yourself at a different point in the project.

2) Educational learning: When you are on a project, in your spare time you come across a new technique someone might have suggested, or read it in a book. You try out some examples, and evaluate to check if it is really a good fit. Once satisfied, you try out the technique in the real project, and once satisfied, bring it up with adapted learners.

This works well with open source projects, such as Accuracy of stormwindproject.org by Bernardo which offers powerful potential over its rivals in Acceptance testing which replaced the existing way of automated testing we were using.

Now, this does not mean all devs can be classified into these two categories, but rather, a pattern of exchange that exists. Someone might know autoboxing, while others may be familiar with generics. All this learning however comes into play via learning exchange that takes place thorugh efficient-pairing as mentioned in my previous blog.

I’ve noticed that once a person starts on a new project, he tries to understand the dynamics and the potentials of the team. About two weeks down, the project team evolves and each person on the project has a small subset of people that he will pair with regularly. This could limit the understand of the keep causing potential problems when rolling-off from a project as well as egos and intimidation (http://en.wikipedia.org/wiki/Pair_programming)

A solution proposed by Eric Plue when he manages his teams is via a pair matrix. This way, he does not assert each day that certain people must pair together, but instead, the team learns self discipline and tries to keep the pair matrix more balanced by making people who pair less, pair more when convenient. This method has been replicated well, as a result the team did not become static after some time, but more results were seen, and knowledge was spread. This is particularly helpful, because if a certain aspect of the code is latent, it may become more clear as long as there is good pair rotation.