Knowledge Sharing in Engineering Teams
The best approach to knowledge sharing in an engineering team is pair programming. Change my mind.
Such a bold stance warrants justification. So here goes. In pair programming, both involved engineers’ minds are simultaneously focused on the code base and problem at hand. The engineer more experienced with the code base imparts valuable knowledge about the code base on the less experienced engineer. This happens while both collaborate to build the next feature increment, fix the next bug, apply the next refactoring - you name it. It’s learning on the job, while it’s being done. The synchronicity of the activity is the key to its twofold benefit.
Other forms of knowledge sharing often used by engineering teams are - in increasing order of utility and value - written documentation, knowledge sharing sessions, live coding sessions, and mob programming.
Written documentation is good and important, but does not adapt to the coding situation: it needs to be consulted as an information source on the side. Also, it’s written by someone at some point, and later consulted, typically by someone else. Two people invest time, independently from one another.
Knowledge sharing sessions are great because they introduce the Q&A element. They take place independently from problem solving activities however, and preparing them takes time (if they are prepared at all).
Live coding - which could be an unprepared knowledge sharing session, so to speak - is good because it’s interactive and in the problem solving situation. It does, however, typically involve a comparatively large and mostly inactive audience and no task switches.
Finally, mob programming: this is pair programming, but with more people. Its main drawback is that it binds much more people than pair programming.
There are valid usages for each of these. I will stand by my initial opinion that if knowledge sharing is needed, pair programming has the best combination of involving the right number of people whilst at the same time guaranteeing productivity.
Tags: work