4 ms·

Thanks, this is the exactly correct critique of the article. I'll just add that the author did not seriously grapple with the fact that leaving at least some e

Thanks, this is the exactly correct critique of the article. I'll just add that the author did not seriously grapple with the fact that leaving at least some explicit knowledge undocumented is inevitable. There is no sharp divide between "explicit knowledge every programmer should know" and "explicit knowledge that only makes sense in our organization". Documenting is costly to produce, and documentation is costly to maintain even after it is produced. (If nothing else, more documentation makes it harder to search.) This holds even if it's simultaneously true that large organizations usually document insufficiently because of laziness and bad incentives.

er4hn 3y ago
I agree that some is inevitable, but as that amount increases it will provide a drag in what the organization is able to accomplish. This becomes even worse as an organization is remote locally and globally spread out.
- k_process 3y ago
  The challenges with the post's suggestion are (1) it accounts only for the time of the person needing information, not the one providing it, and (2) a specific question takes a small time to answer, but pre-documenting everything that is needed to answer any question takes orders of magnitude more time. Some of this is outlined in Snowden's (not that Snowden) Laws of Knowledge Management. http://www.gurteen.com/gurteen/gurteen.nsf/id/km-seven-principles http://www.gurteen.com/gurteen/gurteen.nsf/id/km-seven-princ... These two are especially relevant: 2. We only know what we know when we need to know it. 7. We always know more than we can say, and we always say more than we can write down.