On Being Dumped into an Existing Project

No link or anything, just some musings sparked off by what one of my students is about to embark upon, which chimed with some of my own experience. I found myself on both sides of the same knowledge divide at various times. First as the have-not, then as the have, or rather, once-had.

I asked my student if he had some headway with developing some descriptive models or frameworks for learning and knowledge processes? In truth, we are still looking for generic or well-worn models in this area.

I had some overlap with this topic, which sparked this post, when a colleague consulted me on a project she had become involved with. This is a data analysis and instrumentation calibration exercise that I had worked on some years before. It is one aspect of a larger system of instruments and spacecraft. We discussed what it was like to join a pre-existing technical community.

We both felt that the experience of climbing aboard an ongoing project is typically likely to have a confusing aspect. There might be several hundred documents (or software code examples) that serve as the reference literature, but it will not be clear to an outsider what the relationships between them are. Strategies to improve this might involve indexing or tagging/keywording collections of documents, or for a documentation writer to write meta-documentation that assumes particular specimem tasks, and guides the user through the documentation as much as the task itself.

Workers already on the team might be unable to articulate their knowledge in a way needed by the new arrival, especially if the newbie's question is regarded as trivial. A very advanced query might get rapt attention, on the other hand. This is a cultural and/or timescale issue.

Finding the right mentor is a crucial step - someone with the time to deal with enquiries, with sufficient expertise, and yet empathy for the learner's point of view.

Another strategy of acquiring knowledge is to proceed in chunks, studying some aspects of the functionality of the system in isolation.

As the learner grows in knowledge, one way that they deal with the confusion is start gathering references to the body of knowledge, and building a store of useful links - a subset of the entire content set.

Later, when they are able to describe their work process in relation to the existing system (which might be different from everyone else's process) it can be documented and added to the system archive. This documentation activity is a valuable learning tool for the author.

There are difficulties in ensuring that this new secondary knowledge does not itself become lost in the body of knowledge. In some cases there can be barriers to such publication or amendment of the archive (configuration management system?). Knowledge systems should have an alternate channel (preferally collaborative such as a wiki) or allow grades of control. If the quality system demands the perfect document it will never get written (and will hence cause product quality to suffer).