Live data from Hacker News

Tacit Knowledge Is Dangerous

er4hn.info

61–70 of 143 posts

Re: Tacit Knowledge Is Dangerous

#61
post #7

> Tacit knowledge, often called “tribal knowledge” in tech, is prevalent in this industry. Tacit knowledge is not the same as tribal knowledge. Tribal knowledge is undocumented stuff. Tacit knowledge is about things that cannot be learned from documentation. Riding a bike is an example of tacit knowledge. No amount of reading about the theory of riding a bike will teach you how to ride a bike. You have to hop on the…

I wrote a very similar comment and you beat me to it by one minute! Deleted and reposted below for compactness. Their usage of “tacit knowledge” is different from the most common usage. Tacit knowledge ≠ tribal knowledge. Tacit knowledge isn’t knowledge that no one has bothered to write down. It’s knowledge that is inherently difficult to write down. Riding a bike is tacit knowledge. Knowing when a class is doing “to…

Thanks for the comments everyone. You're not the first ones to give me feedback about co-inflating the two. In my mind saying that something is "hard to" write down is still pretty similar to saying it is not written down.

For one, if you say it's hard to write something down, you're setting yourself up for a scenario where judging outcomes based on that lack of written down knowledge is going to be painful. For example: "It's hard to describe how to write good tests, so we didn't write it down. But we also want our tests to be more reliable." How do you solve the two without writing down some way to learn how to be better at tests?

Likewise, if you want to learn how to ride a bike, how do you get started? Back in the pre-covid days you could do a lot of experimentation and learning from others in person, but that doesn't scale as well in the post-covid, remote and global, workplace. That's one of the core concepts I was trying to capture.

Re: Tacit Knowledge Is Dangerous

#63
post #11

Tacit knowledge is inevitable... but it's also different from what this article is about. Tacit knowledge is the kind of knowledge (and skill!) that cannot be fully explained or taught in words—think mechanical skills you can only pick up through physical practice or very context-specific expertise you only get through experience. In programming good taste is crucial and entirely tacit: we can try to distill taste in…

It's worth noting a tautology: tacit knowledge is undocmented because it is undocumentable. The key insight (which I agree with!) is that some kinds of knowledge are undocumentable. The challenge - at least for those charged with ensuring processes are documented - is deciding what is and what isn't documentable.

I have a lot of habits because of lessons I've learned. There are 100 ways to do it, I chose 1. Documenting the 99 is unreasonable, but that's tacit knowledge, isn't it? I will document why I didn't choose the most obvious one, though.

Re: Tacit Knowledge Is Dangerous

#64
I used to work with a smart guy who had what I think is the real answer to this problem. All documentation is maintained by the newest member of the team. The new guys job is to solve all of his issues with the documentation and if he has to ask someone then his job is to update the documentation.

Re: Tacit Knowledge Is Dangerous

#65
post #11

Tacit knowledge is inevitable... but it's also different from what this article is about. Tacit knowledge is the kind of knowledge (and skill!) that cannot be fully explained or taught in words—think mechanical skills you can only pick up through physical practice or very context-specific expertise you only get through experience. In programming good taste is crucial and entirely tacit: we can try to distill taste in…

This. This article confuses tacit knowledge for the phenomenon most eloquently described by a former (superb) sysadmin colleague “documentation is the enemy of job security”.

One should not look to be unreplaceable, but rather the opposite.

Only when you become replaceable at a certain task (or able to delegate it) you can progress to do new (more interesting) things.

Re: Tacit Knowledge Is Dangerous

#66
post #11

Tacit knowledge is inevitable... but it's also different from what this article is about. Tacit knowledge is the kind of knowledge (and skill!) that cannot be fully explained or taught in words—think mechanical skills you can only pick up through physical practice or very context-specific expertise you only get through experience. In programming good taste is crucial and entirely tacit: we can try to distill taste in…

This is so meta. Here we are trying to verbalize our tacit knowledge of "tacit knowledge" :)

While I agree with the distinction you made (Last paragraph is excellent), there is this grey area : Because in the digital era almost everything is recorded (oral meetings/written chitchat...), there is a huge quantity of information that is neither in the "Guts" nor in the "docs". To join others in this thread, I guess LLMs will play a big part in making this grey area usefull and in a certain way bridge the gap (partially) between what is tacit and what is formally documented.

Re: Tacit Knowledge Is Dangerous

#67
post #11

Tacit knowledge is inevitable... but it's also different from what this article is about. Tacit knowledge is the kind of knowledge (and skill!) that cannot be fully explained or taught in words—think mechanical skills you can only pick up through physical practice or very context-specific expertise you only get through experience. In programming good taste is crucial and entirely tacit: we can try to distill taste in…

It's worth noting a tautology: tacit knowledge is undocmented because it is undocumentable. The key insight (which I agree with!) is that some kinds of knowledge are undocumentable. The challenge - at least for those charged with ensuring processes are documented - is deciding what is and what isn't documentable.

It's a definition. I suppose definitions are tautologies by definition though :)

And yeah, the real insight is not the definition but the fact that tacit knowledge is inevitable and important, and that trying to eliminate it will be actively counterproductive.

Re: Tacit Knowledge Is Dangerous

#68
> You may really need to know about the whizbang service, but it’s been 4 years since anyone last worked on it and no-one remembers how it works. You’ve now fallen into the trap of tacit knowledge.

This article is bad. What it describes - as others have pointed out - is not "tacit knowledge". It merely describes a problem with lack of documentation.

"Whizbang service" can be documented. You can write a diagram laying out the main components, write a small readme on how to build and run locally on against some staging environment, perhaps even having some internal wiki with a internal runbook of what to do when the service goes tits up.

None of this would touch on "tacit knowledge". Tacit knowledge is there when I get a stack trace, and I already sort of suspect what happened without having to spend hours digging too deep on why. Or when I see some latency metrics for my service, and my first instinct is checking on Slack for deployments on dependencies. You can try to document those things, but it is a fool's errand - you'll end up with a huge mess of text that will work against the purpose of documentation.

Re: Tacit Knowledge Is Dangerous

#69
post #57

Per other comments here, this is not what tacit knowledge is. There is an entire body of research devoted to understanding tacit knowledge. Anyone interested in tacit knowledge can read the works of those who have spent years researching the topic. Here are some sample papers. Nonaka is perhaps the most well-known one in this space. Hadjimichael, D., and Tsoukas, H. 2019. “Toward a Better Understanding of Tacit Knowl…

Thanks I appreciate this. I know I co-inflated different concepts. I should update my blog post once the comments here dry up and I can go through them.

Re: Tacit Knowledge Is Dangerous

#70
post #11

Tacit knowledge is inevitable... but it's also different from what this article is about. Tacit knowledge is the kind of knowledge (and skill!) that cannot be fully explained or taught in words—think mechanical skills you can only pick up through physical practice or very context-specific expertise you only get through experience. In programming good taste is crucial and entirely tacit: we can try to distill taste in…

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…

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.
Post reply on HN