4 ms·

No, I don't think it's a misuse of the word "tacit". It's a spectrum which has boundary line on one side only, but is open-ended on the other side. The boundary

No, I don't think it's a misuse of the word "tacit". It's a spectrum which has boundary line on one side only, but is open-ended on the other side. The boundary between the unspoken and the codified knowledge is clear-cut. The unspoken and unspeakable are just one spectrum, and the author's model does not have a boundary between them nor does he seem interested in finding such boundary. In other words the unspoken knowledge can be learned from two sides, not one. It's understandable that the author focuses on their side, but I don't think he does so with the intention to discourage "the effort to make [the knownledge] explicit".

shkkmo 5y ago
The author doesn't acknowledge any sort of spectrum and makes a general statement that trying to make tacit knowledge explicit is so hard as to be pointless to try. > My take on this is that it is so difficult that we shouldn’t even bother; assuming that you are reading this because you want to get good in your career, you should give up on turning tacit knowledge into explicit knowledge and just go after tacit knowledge itself.
- kubanczyk 5y ago
  Maybe it's just my reading, but what follows this excerpt puts it in context. I.e. we shouldn't bother with converting the entirety of unspoken knowledge in some field: > Why do we know this? > [What many researchers found out] was that it is extremely difficult to encode all the possible branches and gotchas and nuances from a human expert into an expert system.
  - shkkmo 5y ago
    But the author doesn't say "don't only try to turn implicit knowledge into explicit knowledge", he says "you shouldn't even bother". To me that sounds like a direct analog to "nobody will ever understanding everything about the source code without reading it, so we shouldn't bother with documentation". Obviously we can't / shouldn't document everything, but creating documentation as you learn an undocumented legacy code base can be of great value (as can asking other developers to explicate their implicit knowledge). Over and over the Author ignores the unexplicated but explicable and assumes that implicit knowledge is inexplicable.

shkkmo 5y ago

The author doesn't acknowledge any sort of spectrum and makes a general statement that trying to make tacit knowledge explicit is so hard as to be pointless to try. > My take on this is that it is so difficult that we shouldn’t even bother; assuming that you are reading this because you want to get good in your career, you should give up on turning tacit knowledge into explicit knowledge and just go after tacit knowledge itself.

kubanczyk 5y ago
Maybe it's just my reading, but what follows this excerpt puts it in context. I.e. we shouldn't bother with converting the entirety of unspoken knowledge in some field: > Why do we know this? > [What many researchers found out] was that it is extremely difficult to encode all the possible branches and gotchas and nuances from a human expert into an expert system.
- shkkmo 5y ago
  But the author doesn't say "don't only try to turn implicit knowledge into explicit knowledge", he says "you shouldn't even bother". To me that sounds like a direct analog to "nobody will ever understanding everything about the source code without reading it, so we shouldn't bother with documentation". Obviously we can't / shouldn't document everything, but creating documentation as you learn an undocumented legacy code base can be of great value (as can asking other developers to explicate their implicit knowledge). Over and over the Author ignores the unexplicated but explicable and assumes that implicit knowledge is inexplicable.