Tacit Knowledge Is Dangerous | Hacker News Reader

Tacit Knowledge Is Dangerous

er4hn.info

159 pointsWingy140 comments

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 into words and write books about it, but it will never be enough.

Tacit knowledge is not the same as explicit knowledge that just happens to not be documented. Tacit knowledge is not documented because it is undocumentable. You cannot avoid tacit knowledge. Human language fundamentally cannot express all the knowledge that experts develop through years of practice and experience. Even if an expert can express their experience, there are simply ideas and skills that people cannot learn exclusively from words.

This is an important distinction. Trying to eliminate undocumented explicit knowledge is useful for teams. Trying to eliminate tacit knowledge is disastrous. I've seen attempts to make tacit knowledge legible to management—it is one of the most direct ways to sabotage your own experts because experts fundamentally cannot make all their knowledge explicit. Expertise is tacit knowledge and tacit knowledge is expertise.

People generally understand that design by committee or design by regulation has awful results; one of the main reasons for this is that committees require decisions to be fully explicit and explainable—which hamstrings creative problem-solving and pushes for poor design decisions. Exclusively explicit processes get you lowest-common-denominator results: not the lowest common denominator of the expertise present, but the lowest common denominator of what people can explicitly communicate and understand, which is even lower! If you don't let experts be experts, you won't get expert-level work.

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.

It could go either way. Some places will like and promote one to do different/more interesting things. Other places will eliminate the position with k, thx, bye! Moreover usually people have only so much energy to be always concerned with job / career growth/ changes etc. They are fine their little pieces of knowledge that make them useful at work in a unique way.

If your company has a habit of firing people that share information, or punish employees who work smarter instead of harder, it’s a sign that they might be out of touch with value creation and will eventually be punished by the market.

Being fired from such a place might actually be a blessing, not a curse.

Is this true, though? After seeing enough bone-headed management decisions, I wonder if the bosses even know or care about documentation when making decisions to fire someone.

From my point of view, the lack of documentation might be a reason to fire someone.

Was just arguing with my father whether the difficulty in transplanting TSMC was due to tacit knowledge or missing documentation. I argued that an automated process failing to run would inherently be missing documentation but I'm curious to see what kind of tacit information would be involved here.

Documentation makes the world go round. Definitely appropriate for high-risk must-deliver projects, but not in all contexts. Is it maybe a business fantasy that we can simply juice the talent of a team and bottle it?

Where does this idea come from other than good engineering practice?

If you work with smart, talented people in a fast moving world it seems, as you say, inevitable that you face the "problem" of tacit knowledge and manage it positively.

In Designing Sound (and my lectures on sound design) I researched and wrote about this as "ineffable knowledge". My observation in arts and design through the 90s and early 00s was that we regularly get people who are x100 superstars but they're unable to articulate exactly how they do things and pass that knowledge to others (I was researching this from a UI/UX point of view). That is /talent/ and it's why we value people as more than just interchangeable cogs. Much process knowledge, and crucially problem-solving knowledge in any project will reside in the heads of individuals.

(TBF I think the article is more about tacit cultural knowledge within the team as a whole)

Sure if we lose key individuals the project is threatened, but on the other hand trying to get them to do a full knowledge dump, such that any replacement would be frictionless, is a fools errand.

Treating "information" that way and ignoring people is one-dimensional thinking.

So I don't think it's helpful to talk about tacit knowledge itself as "dangerous". What is more dangerous is composing mediocre teams only from replaceable workers and spending too much of their time on documenting as a safety net when they should be pushing forward. Meanwhile a danger is in treating valuable people so badly their continuity is not assured. Far fewer people fall under the proverbial bus than simply leave for better jobs.

So we could take the view that over-cautious self-reporting and documenting is a sign of, and attempt to manage, low commitment business attitudes, poor wages, conditions and low job-security.

Documentation is one of those things that once there's a lot of it, it's its own product.

First, you have to have someone constantly making sure it's up to date in the case of software. Really easy for it to go stale and just be wrong, and possibly actively harmful.

But then telling someone "RTFM" has a different quality if you're talking about 50 pages or 50,000 pages. Cool, I'll get back to you in a month.

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.

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.

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.

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.

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-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.

I think almost all knowledge is tacit knowledge. Even stuff that would seem obviously explicit like mathematics and language.

In my experience tutoring high school students, I’ve encountered plenty of students who struggle with spelling, grammar, or mathematical mistakes and no matter how many times I correct them it doesn’t stick. Then I see other students who pick these things up so quickly without correction.

Mathematics, especially, seems to have a strong tacit component. If all you do is read the textbook you’re going to bomb the exam. You need to practice a lot to develop your mathematical intuition.

>> Tacit knowledge is not documented because it is undocumentable

> students who struggle with spelling

The ability to spell correctly is not tacit knowledge.

>> Tacit knowledge is not documented because it is undocumentable

Spelling is thoroughly documented.

It is thoroughly documented, yet alot of people make spelling mistakes and we sometime make up animals to mock people who spell stuff "as it sounds in their heads". And then there's people who are good spellers, whomst wouldn't blink twice or use Google when asked to spell "accommodate" or "nausaeus". Do you think that these mega spellers can document _how_ they spell correctly all the time? Or do you think they have some good intuition/tacit knowledge?

English is my second language so I tried to make some funny mistakes above due to the topic, but there might also be some unwanted/undocumented ones thrown in for good measure.

> Do you think that these mega spellers can document _how_ they spell correctly all the time?

At least in my native language, I can typically explain the rules why a word is spelled the way it is. The simple reason for this is that I am interested in the structure of languages. The typical reason that I experience among other people why they spell words wrong is that they are less interested in this topic.

There are rules for English spelling. They’re just extremely complicated because English, in addition to all its Anglo-Saxon native words, has many loanwords from other languages: Norman French, Latin, Greek, German, and many more. To spell a word correctly it really helps to be able to identify its language of origin. If you watch the Scripps national spelling bee, you’ll regularly see the spellers asking about this information.

Of course, tons of everyday great spellers don’t know about any of this stuff explicitly. They just seem to tacitly have a “feel” for the language of origin and are thus able to spell many words when first hearing them.

Lots of words have odd spelling due to false etymologies.

Scissors, Island, Ache, and Could; were all from old English with random letters added by people in the 15th century who mistakenly thought they were from Latin.

Etymology is hard, and most textbook writers and teachers who invented the rules weren't qualified to actually find the true origin.

English accumulated a multitude of inconsistent spelling patterns, some from loan words, some from shift how words pronounced from vowel shifts, yod-dropping, and random reform attempts which weren't often based on rigourous evidence of origin.

It was an etymological fallacy that drove those spelling reforms to 'correct' the spelling anyway.

There is no real value in keeping the k in knife when the sound was dropped as an example.

Lots of words have odd spelling due to false etymologies.

That's true as well.

It was an etymological fallacy that drove those spelling reforms to 'correct' the spelling anyway.

There is no real value in keeping the k in knife when the sound was dropped as an example.

To me, these two statements suggest opposite recommendations. The first tells us that we should be cautious of prescriptive changes to spelling. The second that we should go ahead and drop the k in knife (and presumably change the spelling on all other words to be more phonetic).

I am inclined to be conservative here [1]. I found Mark Twain's satirical piece on the issue [2] rather persuasive. Like it or not, those old prescriptivists' changes have become part of the etymology. Making further changes for the sake of easier spelling would only complicate the etymology even further, and make it even harder for future English-speakers to read the texts of today.

[1] https://xkcd.com/927/

[2] https://faculty.georgetown.edu/jod/texts/twain.html

A lot of then simply remember well. That is not tacit knowledge, that is explicite knowledge.

Like "i" before "e", except after "c"?

While "i" does come before "e" nearly 75% of the time—even after "c" it is a probabilistic rule and not particularly useful.

So not so well documented.

Or how about the false rules that people tried to copy from Latin to English that don't really apply like double negatives or split infinitives.

Shakespeare loses most of its humor in modern edited versions, he used spelling and homonyms artfully when he cared at all. Look at the first folio version if you haven't.

Standard spelling is useful, but neither fully documented nor close to logical.

I think you will find that actual linguistic scholars error twords descriptivism vs prescription.

Only the less informed population of lay people stick to the prescription model as a proxy for intellectual ability.

Random cite describing the difference:

"Prescriptivism is the term used for approaches to language that set out rules for what is regarded as “good” or “correct” usage. Descriptivism is an evidence-based approach to language that describes, in an objective manner, how language is being used. Most contemporary academic linguists are descriptivists, but prescriptivist approaches abound in schools, style guides, internet comment threads, and parental chidings. This case examines attempts to govern, reform, and/or reimagine English."

https://exhibits.lib.ku.edu/exhibits/show/english-language/g...

> So not so well documented.

You're criticizing a rule of thumb, here. Sure, the rule of thumb isn't perfect … but it also never claimed to be.

But from that, you're drawing the illogical conclusion of "spelling isn't documented", which … the aforementioned rule has no logical connection to.

Plenty of dictionaries exists, good ones, ones that even document non-standard spellings or local variants.

> I think you will find that actual linguistic scholars error twords (sic) descriptivism (sic) vs prescription.

I'll highlight the irony, but this is besides the point, but doubly so when teaching someone how to write. You start with the prescribed spellings, and once the skill is mastered, or the language evolves, then either they know when to break the rules, or the new spelling is simply trending towards prescribed.

… it's the same for a lot of pursuits: in dance, we teach footwork first. Later, you learn when to bend the rules, and when to outright break them. I'd say it's the same in music, too.

> Only the less informed population of lay people stick to the prescription model as a proxy for intellectual ability.

This really isn't what upthread is trying to say, at all. If I had to rephrase it, they're suggesting that, when you teach spelling, some "get it", some don't, even repeatedly, and questioning whether there is some tacit knowledge that the first group has formed that the latter is struggling with.

I taught CS, and I'd say there is a similar pattern amongst students there. Some intuitively seem to get it — particularly, once given the rules for syntax, ifs, while, etc., how to synthesis new programs to solve until-then unseen problems. Yet other students struggle with this. (The closest I've come is "the former have a decent rule system/model in their heads, and the latter are just trying to bum by on heuristics.)

> Like "i" before "e", except after "c"?

> While "i" does come before "e" nearly 75% of the time—even after "c" it is a probabilistic rule and not particularly useful.

That's only the first part of the rhyme. The second part is "or when sounded like 'a' as in 'neighbor' or 'weigh'", which handles most of those exceptions.

There's even a third part I remember hearing once, but can't remember it now.

Most English spelling/pronunciation rules are never explicitly taught, but they do exist - it's why "ghoti" isn't pronounced the same as "fish", to get that pronunciation you have to break at least two rules.

Years ago I found a page that listed like 40 or so English pronunciation rules that had to do with combinations of characters and where they appeared in words, it was really thorough and I wish I'd kept a link to it.

> I’ve encountered plenty of students who struggle with spelling, grammar, or mathematical mistakes and no matter how many times I correct them it doesn’t stick. Then I see other students who pick these things up so quickly without correction.

I often wonder about this. I believe that each person has a certain intellectual threshold beyond which they cannot progress farther in (memory, spatial reasoning, logical reasoning, learning speed, etc.) Logically there are genetic and natural components to this threshold. I also think part of what makes a lot of modern life so disastrously ineffective is the belief by those running society that everyone can reach a similar intellectual level given the right "system".

However, I think modern schooling is so brutally ineffective that barely anyone in school is operating near the real limits of their intellect. What do you think was holding those kids back? Lack of motivation, poor knowledge of fundamentals, or do you think basic high school concepts actually had maxed out their intellect?

As someone who suffers from dysgraphia, which isn't well understood and commonly missed or completely misunderstood, our teaching methods simply do not translate to effective methods.

In English especially where we have problems with vowel shifts multiple source languages and frankly stupid spelling of some words by ignorant prescriptivist Latinophiles, it is really rote memorization.

Math is like playing the guitar or skiing, it takes practice to be good at.

But if you aren't good at memorization of concepts you don't understand, the typical response is to make people spend more time with memorization.

This simply doesn't work and students start to believe they aren't smart enough and give up, because they aren't offered tools to adapt and it is easier to just be thought of as stupid or slow.

Mathematics, logic, and scientific reasoning are learned skills and while everyone will have ultimate limits to their abilities, they are hard for all humans but in different ways.

But you are right, most this is tactic, people just ignore factors that often aren't even learning disabilities, but are advantages some students have due to their history and exposure.

Moravec's paradox is probably a good analogy, where what we think is easy is only easy due to previous experience.

Many authors like Ernest Hemingway and Agatha Christie were horrible at spelling and grammar but had good editors.

Assuming that being bad at spelling and grammar indicates an 'intellectual threshold' is a dangerous path.

Calculus is a filter class because it is taught in a way that favors rote memorization of unexplained concepts, but introduce some abstract algebra concepts to a student or coworker and many can move forward.

Rote memorization does have value, but equating memorization skills wilh ultimate intellectual ability leads to far lower educational attainment for many people.

Great guitarists and other difficult skills are far less about 'natural abilities' than it is about hard work and being exposed to an environment that does discourage that hard work.

Stem is the same as is creative writing or effective communication.

It is hard for everyone to learn, but people forget how much effort it took.

> Moravec's paradox is probably a good analogy, where what we think is easy is only easy due to previous experience.

One explanation of Moravec’s paradox is based on evolution. Human skills are implemented biologically with mechanisms that have been shaped by natural selection. The older the skill, the more time natural selection has had to shape it. Abstract thought is a recent development, so we should expect the current implementation to be relatively inefficient.

> I also think part of what makes a lot of modern life so disastrously ineffective is the belief by those running society that everyone can reach a similar intellectual level given the right "system".

Well, it's a nice belief to have, even if it's not true. But I think what's worse is the belief that everyone can reach a similar intellectutal level given the same "right system".

I'm pretty sure no system could teach me how to say draw legible sketches of pretty much anything, a valuable, intellectual skill. I'm ok with that and will move on with my life. But I'm even more sure a system that could teach me that skill would be unable to teach very many others. If you want to get everyone to the same intellectual level or maybe to at least some specific level, you've got to be flexible about how and what to teach and how long it's going to take.

I know plenty of people who can do basic 3d sketching with no specific instruction, but that's not me. I've got things I can pick up too. Some people are going to need a lot more time for things...

But schools will say they want to do flexible, student driven teaching, but then it's more of the same one size fits some.

>>I know plenty of people who can do basic 3d sketching with no specific instruction, but that's not me

I used to think that I am tone deaf and have no memory for melodies. Bu t after I forces myself to spend a lot of time singing, playing guitar and listening to music it occured that I just lacked some basic skills that combined suddenly creates magical ability of recalling melodies in my head and even repeating them. The same was with drawing and public speaking and general movement coordination (strength training can do wonders in this department).

This made me believe that some of problems of education system comes from general inability to convince students to spend more (dozen times more) on practicing basic skills (being this writing, small/big motoric skills, logical thinking oraz even some seemingly unimportant stuff like voice emission)

I think there are three things here - which are not mutually exclusive.

1. No amount of practice will enable me to break the 100m world record - or even probably be within 30-40% of it.

2. However, training would dramatically improve my time.

3. Most importantly, in life I could beat Usain Bolt by simply starting running 5 seconds earlier - ie for most things peak performance isn't what matters - it's effort/persistence.

Which were the basic skills you thought you were lacking in terms of remembering tone?

I really do not know the proper name here but it is akin to visualisation (but with music). I could not recall intervals and rythm that makes given song recognizable (could not replay the song in my head) just like if you lack visual imagination you cannot solve even the easiest geometric problems without pen and paper or create good shape composition plan for painting.

And basing my intuition on example of one (me) both visual and tone imagination and memory can be developed from almost zero.

How did you develop them from zero if you were missing those basic skills?

I am a musician and I'm keenly interested in music education. I believe you when you say that you lacked some basic facilities; I think it's rare, but more common than people think that someone is genuinely tone-deaf, or can't "visualize" pitches and intervals, or can't memorize songs, or can't feel a rhythm. I always wonder if those deficiencies can be overcome. I'm really interested in your tale, if you wanted to write more privately, would you consider sending me an email? It's in my HN profile.

>> How did you develop them from zero if you were missing those basic skills?

It is really hard to answer this question because it seems that they were an emergent property of dozens of hobbies that I had (I tend to be seriali hobbyist). Seems like trying to explain how I did learn to ride a bike - I can name few basic skills that are required, but showing which exact part of learning bike riding made it stick is no easy task for me (I remember it as trial and error process and this was the same with my children - they just practiced riding bike and the skills developed thanks to them sticking to the practice). It all looks like a kind of tacit knowledge that can only be developed by pure practice (melodic memory through remembering and playing songs, aesthetics through creating your own compositions, logic through solving problems)

My own story is rather simple - I used to play guitar, a bit of keyboard, sing using karaoke, listening to songs paying full attention and than playing guessing games aking to local tv game called "What melody is this?". At first I was awful at this. But then something changed; I started to notice that I can recall melodic and rhythmic structure of some songs - and this was totally new ability to me (I remember that as a kid I was made fun of by my peers that I could not recognize any songs and my singing voice was wildly out of tune).

One caveat though - It's not like I am any good at music - I estimate that getting to level where others would tell "wow you are good" will take at least another 10 years (and it is not that important because I prefer the journey part, not the destination). But still I know I was a lot worse before forcing myself to learn. And probably if I would get a teacher that would motivate me and give feedback I would get here a lot faster, but as I said - it's the journey, and I really like to learn everything myself.

The message here is that I do not think that most people are unable to learn this kind of skills (those being music, logic or even simple aesthetics). The problem is that most do not have the drive, will or simply the time to stick with practice to overcome their own limitations.

>that everyone can reach a similar intellectual level given the right "system"

False on absolute terms and useless for most "real life" training. Time to learn/master a subject is an enormous competitive advantage to foster, as "talented" people will always have an edge over "clumsy" people. Mediocre people can only beat a genius trough effort of luck IF the genius is lazy and/or unlucky.

> Mathematics, especially, seems to have a strong tacit component.

It’s quantifiers, and bound and free variables.

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.

Exactly. However I think its a bit more complicated than a grey area. There is just no hard distinction between tacit and explicit knowledge, even though the distinction is useful.

It is not that any tacit bit of knowledge eludes articulation, it is the whole that is problematic. Nothing is truly undocumentable, but its like the specs for microsoft word: its just so much you already need to be an expert to navigate the whole of it.

Thats the distinction and LLM of course of very good at processing vast amounts of bits and pieces.

> very context-specific expertise you only get through experience.

When giving advice, I'm often tempted to point to a given situation, and to explain what rule of thumb I used to solve it.

But then I would see a junior programmer applying the rule of thumb in a completely different situation and I'd want to say, "No, that will end in tears!" And I realized that a lot of my rules of thumb were really dumb when taken out of context.

As far as I can tell, a huge part of expertise is having a large set of mappings like:

- In contexts like "C1", use rule of thumb "R1" or "R8".

It's very tempting to talk about R1, R2, etc. You can write blog posts like, "How R2 will transform your team!"

But a lot of real expertise comes from being able to say, "Oh, this is a combination of C7 and C78, so I should consider rules of thumb R7, R49 and R102. Ah, wait, no, R49 is just gross here."

So I've learned that, when mentoring, I need to spend a lot more time talking about the context before proposing any rules of thumb.

This is very insightful, thanks. I'm currently in the middle ground where I still want mentoring from the technical leads on some things, but I also have enough seniority to be mentoring new hires. You've articulated the way I think our tech leads are often not great at explaining themselves, while also giving me something to think about when passing on information to newbies.

My rule of thumb is to hesitate before giving advice if I can't come up with an anecdotal story to support it. Stories are more useful than generalizations because they come with the context, and can be dismissed in different contexts. At risk of presently breaking this rule of thumb, I'll give an example. When I notice code being structured with class inheritance, I'll point out a part of the codebase where I did similar, and how poorly it turned out, which someone can observe for themself. It started out nice, as it usually does, but devolved over time as complexity accumulated in parent classes to handle scenarios in child classes.

Um, can I retract about the last 15 years of my advice?

+1.

This[1] article that was on HN front a few months ago and I could only agree with it.

I've seen teams trying to micro-document their way to inefficiency. Forcing doers to document every darned small thing is the surest way to get them to lose interest. By now I've realised that regardless of documentation it takes around 6 months for a s/w engineer to be fully productive at a new company and start creating value.

[1] https://commoncog.com/tacit-knowledge-is-a-real-thing/

Well put!

Donald Schön’s work on this topic is really enlightening. It’s not just that there’s knowledge in the heads of people that can’t be linguistically expressed well, but also that expression of it requires interaction with a specific situation.

This is also represents a massive gap for AI systems to become actual in-the-world problems solvers.

At a previous company where I had a lot of this "tacit knowledge", I had made a policy for myself. Whenever somebody asked me a question over IM or e-mail, I would look in the wiki. If the answer was not in the wiki, I would write a new wiki article or update an existing article with the answer, and I would respond with a link to the article, and a statement like "if this doesn't answer your question let me know what is missing or could be described better." The reasons for this were for me to dump my tribal knowledge out of my brain into something everybody could search and read, and to promote usage of the wiki as a place where people found answers. Unfortunately it did not appear to have another desired effect of getting everybody to contribute content. I think this was probably because people came to see the wiki as a place to find knowledge, not to put knowledge.

How do you keep your wiki from evolving into a kludge of random-ish info?

One example of tacit knowledge is knowing the Dell T420s Tower Servers have very poor cooling for the raid controllers and often, this can cook them over time, requiring replacement or, at least repasting the heatsink.

Now imagine 100s of those little tidbits. Useful, but hard to categorize.

Use an internal Q&A / Quora-style tool with good search. Trying to keep little snippets of info like that under useful MECE categories only ever ends in pain & frequent refactoring.

I don't want to get too much on the ai hype train - but it seems like this would be perfect for machine learning, trained on the wiki-snippets of the company and emails (initiator would have to set a flag saying this is going to be training data).

That would be a good use of LLM AI, imo. Good idea.

> machine learning

This is already kind of skewed by hype. It's not possible to teach a transformer architecture LLM the fact "Dell T420s Tower Servers have very poor cooling for the raid controllers". All that can be done is have a corpus of text where the statistically most likely text associated with a prompts about "raid controller cooling Dell T420" includes the text "Dell T420s Tower Servers have very poor cooling for the raid controllers", or some variant of it. But the model doesn't know that fact, or any other fact, so it's not being taught this knowledge.

Since this is the internet, I'm asking, not arguing...just this time.. ;)

In this context, can we assume AI would be a good internal wiki assistant/Mod?

It could make many data correlations, rapidly, and suggest or act upon migration/collation/etc of information into more useful groupings, with related information automatically indexed and grouped, based on the more commonly searched for terms that match data related, or tagged. This could/would evolve over time, assuming the same AI and a changing team/staff, terms, current in-use hardware, in this case.

A simplified version of what I'm trying to say might be, AI can't know a fact, but it could parse inputs and build relationships between bits of data, based on how the users access that data, and under what headings it's commonly searched for.

An AI, especially the parse/response loop of LLM AIs, seems almost custom built to find that input, and match it with similar/related inputs and store the information in a more effective way, under more commonly searched headings from the users searching the wiki.

Am I missing something?

> AI can't know a fact, but it could parse inputs and build relationships between bits of data, based on how the users access that data, and under what headings it's commonly searched for.

Yes, but so can text analytics tools that are not transformer model LLMs, and they can do it without thousands of swimming pools of water[1] or a gigawatt hour of electricity[2]. Those LLMs are just algorithmic summary generators, and text summarizers have existed for some time.

> find that input, and match it with similar/related inputs and store the information in a more effective way

But that's not how these automation tools work – they don't store information, they generate statistically likely text based on the training corpus.

1. https://www.independent.co.uk/tech/ai-water-energy-artificia...

2. https://spectrum.ieee.org/ai-energy-consumption

Sure. I get that AI doesn't "know" things.

My specific suggestion was about leveraging the parsing and response loop of LLM AIs to analyze free text, parse what's useful and the reply would be collating the data.

Thanks for taking the time to reply!

How can someone do this, concretely? I would love to slowly train an AI to fit the gap between search and one on one assistance, but I don’t know how to do it as a single person running an informative website.

That's what a wiki is good for: collecting snippets of hard to categorize information. If you've got a culture of recording those notes, then you can develop full text search habits.

A kluge of randomish info by people who make occasional attempts to organize and garden... sucks compared to a beautifully manicured knowledge base. But it's fantastic compared to a blank wall and a shrug.

Even this ends up very messy.

The first problem I commonly see is called "Delores Thesaurus". It turns out people find like 50 different ways to say the same damned thing. Maybe with LLM based sentiment search we don't have to be so exact in how people ask the same question?

Also this information getting stale or out of date commonly leads to people not going back and gardening because of the massive amount of work involved, such as adding versioning when you figure out there are 10 different product behaviors over time.

Put it in the runbook for the alarm you got when the server failed, or the maintainance guide that your team runs through every month. Or make heatsink repasting a regular documented process, or something similar.

Basically, as Toyota says, build quality _into_ each part of the product rather than layering it on top by documenting discrete pieces of info that an operator has to discover, understand and act upon

I'm a fan of the toyota approach, but sadly, Dell isn't. lol

I'll review the runbooks. We have a number of them, mostly created by me. :)

Not OP, but you have to regularly review and adjust the ontology regularly as more articles are added.

In short, the categorization and organization is key, and you have to do it when the number of documents is not only increasing, but different enough.

Sometimes, I just write a longer document and once it's ready, it can be broken into smaller ones. Doing this helps save the organization tremendous amounts of time in not having to re-learn things, or dig it up.

Sure, but this then becomes a fulltime role by itself, once the info grows enough.

I maintain it for my teams, but as things grow, it becomes less manageable, since I'm also a T3 and have technical tasks to address, as well management of the teams.

The good news in all of this, is in less than a decade, it'll all be someone else's headache. ;)

Manually, yes.

Using technology not so much.

I have had to live in similar scenarios as you and am solving this problem and have made some headway. Would be happy to listen and learn from your use cases on what did and didn't work for you.

> One example of tacit knowledge is knowing the Dell T420s Tower Servers have very poor cooling for the raid controllers and often, this can cook them over time, requiring replacement or, at least repasting the heatsink.

I don't even think that is tacit knowledge. Tacit knowledge is how do you know when the edge of your chisel is too dull and need re-honing. (It feels off.) Or knowing how much weight transfer you need to safely navigate a given turn with a motorcycle.

Or to grab a more similar example: Tacit knowledge is looking at a computer case you have never seen before and thinking "that doesn't look like enough cooling, we should calculate and check".

This gets muddy real fast.

One could argue that tacit knowledge also applies when it comes to the feel of pulling laptops apart without breaking the tiny little clips. It takes a few before you get the feel for it, because the difference between snapping a tiny little case clip and not snapping it are about 1 psi (borrowing a term) difference..lol

That absolutely sounds like it.

I opened several laptops with spudger tools. Now I can open random items I didn't watch videos for just because I have an idea of how it _might_ be assembled.

> One could argue that tacit knowledge also applies when it comes to the feel of pulling laptops apart without breaking the tiny little clips.

I agree that that is tacit knowledge.

> This gets muddy real fast.

I don't see how your example demonstrates the muddyness?

it kind of blows me away how many people on these forums don't know what tacit knowledge is.

tacit knowledge is being able to ride a bicycle.

You'll never describe it well enough that a child can hop on the bicycle and ride it the first time.

the knowledge that enables someone to successfully ride a bicycle is tacit knowledge.

I've explained bugs and developed exploits just from noticing odd behavior in video games.

I know how a team is organized, I knew the multiplayer feature was tacked on (probably by interns), I know about network code edge cases, bada-bing bada-boom I can trigger a bug and understand why it happens without ever seeing their code.

Or sitting in a theater and just noticing the lighting setup and transitions rather than the performance itself.

I write documentation for a living and refactoring is a significant part of my work. Keeping documentation tidy is a full time job.

Another nice hack is to record a video as an answer, and put in the wiki doc, and then email a link to the wiki doc.

The explanation by IM/em can be troublesome because it could be out of date.

Helping your organization be creators is the way to go.

I know many people love video, but I personally think this is only slightly better than not recording it anywhere. Video is much harder to search and nearly impossible to skim, so it's difficult to use for anything other than a classroom-style "let's sit down and learn" session.

Most often I'm looking for some particular piece of information. Finding a video that _may_ contain the answer _somewhere_ in the hour (or whatever) of information just means now I have to decide on the likelihood that it'll be worth trying to watch.

Yes, some things are better explained in video format. But not very many, especially in knowledge work.

ETA: Also video is much harder to update as the situation changes. For the most part you just need to re-record the whole thing, which probably isn't going to happen.

These are great and specific scenarios. I'm working on a solution for all of the points noted above, including updating video.

Would be happy to chat to learn any more you may have :)

There are different tools that handle aspects of the valid things you're pointing out.

I often create wiki pages to save myself the work of explaining it multiple times to different people. Ultimately, it's win-win. I don't have to put in more effort to explain something, and the requestor has the necessary information.

If other people don't contribute to the wiki then it's likely that there's nothing incentivizing it. It's not like management is handing out bonuses to people contributing to the wiki. Heck, even my contributions are self-serving.

Maintaining wiki requires a lot of time. Even just adding new content is much more work than a reply over IM/email because one needs to find a right place (if stricture is not completely flat), explain the context (which people exchanging messages have but would be missing for someone who would read wiki), organize content so it has some internal structure e. t. c. And there is a bigger problem - wiki to which new pages frequently added typically full of outdated or no longer relevant information. Updating or archiving old wiki pages requires a lot of time too (and this work sometimes can be done only by an author or someone who knows subject equally well).

It is nice to have knowledge documented, but there is a tradeoff between time spend on wiki and time saved thanks to the wiki.

That's what I did at my last job, now I mostly feel like that was a mistake. I was the guy contributing 90% of the wiki knowledge, for no real appreciation or incentive. And when something I posted inevitably become out of date and caused a problem for someone, guess who got blamed? I feel like I was enabling the team's bad habits.

At $NEW_JOB I'm just putting everything into my Obsidian repo. It's great because I have complete freedom to refactor my notes however and whenever I want. When someone has a question for me, I just look up the answer in my notes and send it over to them. Then they'll copy it into their OneNote, and everyone is satisfied.

This isn't my ideal world, but this seems to be the state of equilibrium when management doesn't lay down any expectations or incentives.

This is a perfect example of poor organizational incentives.

Interesting story about where blame is placed, and your move to Obsidian. Thanks for sharing.

I've actually done something similar to your Obsidian repo: I put all my notes into markdown and publish them with mkdocs[1]. This gives me the same editorial control and freedom from blame as your notes, but mine are public by default, so I can still simply reply with a link. I just can't post anything that is sensitive, which hasn't been a significant drawback yet. I have considered moving to an Obsidian based system, but have yet to find something compelling enough to make the switch. It looks like an awesome app though and is still on my radar.

1. https://danielhoherd.com/tech-notes/exiftool/

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 Knowledge in Organizations: Taking Stock and Moving Forward,” Academy of Management Annals (13:2), pp. 672–703. (https://doi.org/10.5465/annals.2017.0084).

Huang, X., Hsieh, J. P.-A., and He, W. 2014. “Expertise Dissimilarity and Creativity: The Contingent Roles of Tacit and Explicit Knowledge Sharing,” Journal of Applied Psychology (99:5), pp. 816–830.

Nonaka, I., and Von Krogh, G. 2009. “Perspective—Tacit Knowledge and Knowledge Conversion: Controversy and Advancement in Organizational Knowledge Creation Theory,” Organization Science (20:3), pp. 635–652. (https://doi.org/10.1287/orsc.1080.0412).

Nonaka, I. 1994. “A Dynamic Theory of Organizational Knowledge Creation,” Organization Science (5:1), pp. 14–37.

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.

> 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 bike and fail a few times until you figure it out.

In software engineering, tacit knowledge are things like "How to factor a system so 50 engineers can work together without stepping on each other's toes" and "How to structure your files to naturally reduce architectural complexity" and "How do you write a useful test that isn't just writing tests for the sake of tests". You can read about these things all you want, but you can only learn by experience. You have to get it wrong a bunch of times, see how it was wrong, and then you eventually start doing it less wrong.

Learning by example also works to speed up the process.

But that's not the same as undocumented.

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 “too much” is tacit knowledge. Knowing that the internal account must be created before the external account is not, but it’s the sort of thing that they’re talking about.

I wouldn’t make such a big deal about semantics but it’s the title and the first few sentences of the blog post. I expected something very different than “tribal knowledge is bad”.

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.

Being pretty blunt here. I have a hard time taking your suggestions on documentation seriously when you’re redefining a well established term.

“Tacit knowing” was introduced by Michael Polanyi in 1958. Its meaning has generally held in modern usage.

https://en.m.wikipedia.org/wiki/Tacit_knowledge

There’s also a meaningful critique here that documentation is not a solution to tacit knowledge sharing. It doesn’t work. To answer your bike question, you learn a bike by riding it. There’s skill progressions and tips and mental models to share, but you absolutely can’t learn to ride a bike by reading docs.

There are skills that are only learned through experience and mentorship. People try otherwise and it usually fails. Do you have evidence otherwise? Do you have a case where you were able to pass tacit knowledge efficiently to a large group of people through docs?

This looks like a really good use case for LLMs. When you're small and starting out in person, record everything the dev team does -- meetings, whiteboads, pairing sessions, etc. (yeah, creepy, but I'm in brainstorming mode) and then as you start to scale beyond the ability to "ask someone who knows" trail up an LLM to serve as the 24x7 lore master.

This is very much like my panoptic computronium cathedral™. I only need $80B to build it to achieve AGI. The AGI requires 24/7 surveillance for making optimal decisions because it needs access to as much information as possible. The second stage will require worshipers to ingest nanosensors so that even their bowel movements can be tracked and analyzed by the AGI. This is all for the benefit of those who are under constant surveillance in the cathedral.

Surely I wouldn't need to ingest anything to monitor my bowels, mightnt I simply insert a device up my ass?

Intriguing possibility.

It's more robust to have multiple modalities, so you really ought to do both.

A loremaster who will lie when they don't know the answer instead of saying, "I don't know".

At which point it becomes the Dungeon Master

Funny joke and not inaccurate, but as a regular Dungeon Master, there have definitely been times where I'll say I don't know! For example:

- "Sorry, I'm not sure right now how that class feature would work in this situation. For now, let's assume it works like X so we don't have to bog down the session to google the answers or scour the books, and I'll take the time to look it up later and make sure we do the correct thing going forward."

- "You know what, I actually don't know what happens in this kingdom if the king is incapacitated, but still alive, I didn't think to prepare for that scenario! Um, roll me a history check, and if you get a 15 or higher, then you'll have heard of this happening before, and you tell us what happens!"

- "Ok friends, I didn't expect you to just go north into the woods and build a raft to cross the river. I literally have nothing prepared for this scenario, so instead of me making up something bad, let's call the session for now, and I'll prepare something that I know will be fun for next time."

My dungeon master has done similar things in the past. I do love finding out, after a campaign, that a favourite npc or room was made up on the fly after we did something unexpected though!

I especially like your second example. Rule of cool + added space for role play.

Ah, nice, like feeding a custom GPT everything that goes on at the company. That seems dangerous to me, and not in the typical LLM weariness way.

Meetings can be messy, full of ambiguity, and "unsolved" at then end. If you feed a number of these experiences into an LLM, would its knowledge base be _that great_ at helping teach somebody about the company holding said meetings?

I'd argue that in order for your LLM suggestion to be effective, the input to it would need to be human-written content. I.E: the knowledge that the OP is discussing. In that case, the human effort is still required up front.

It would be interesting to see if you could train a LLM, given "<A> The foo is definitely xyfied" to exclusively answer "Well, at least two months ago, A thought that the foo was xyfied" rather than opine about foo directly.

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.

This is an odd definition for tacit knowledge. My understanding is that it's more caught up in the intuition of concepts/systems that's difficult to codify because it's very contextual. This "tribal knowledge" perspective seems more like processes and facts that aren't documented. Not because of the inherent difficulty but instead because of priorities. Not that there isn't some intersection between the two.

Well, as in all of these absolutist black/white, binary statements, "it depends."

In my experience, tribal knowledge, which also includes cultural inculcation, can be the difference between success and failure. Sometimes, on the success side, and, sometimes, on the failure side.

The main thing about "tribal knowledge," is that it relies on long-term association/employment, and that is not something we see much of, these days.

Come now Chris, you know articles like these are cat nip for the HN circlejerk. Put up a straw man and then beat it down over and over again.

PS. I loved the page you put up of your dad a few days ago and mentioned in the thread about diplomacy. Very interesting person.

Surely there are tribes that transcend and cross corporations. That's why you can hire old colleagues and get a team up and running in a startup or new firm

That would be "association."

But there is also a great deal of extremely mercenary behavior, in today's workplace (not just tech).

I suspect that it would be hard to have contiguous relationships.

I worked at my last company for 27 years. I knew many folks for decades.

I believe that this kind of thing is ... uncommon ... these days.

Perhaps such products are in the works, but I would love a private company LLM that slurps all messages, docs, meetings, and becomes an oracle that can be relied upon. Perhaps it could even infer tacit knowledge even when it's not explicit in any docs, since it could abstract principles and concepts from the maze of data.

Such an oracle would be a devastating thing to lose to industrial espionage.

Indeed it would. But then the source training data would be bad to lose too. That already exists. I understand it would be a higher level of damage to lose the model of course, but the benefits outweigh the risks, and these could be managed via a very security-hardened product.

I think being able to steal a language model that can instruct you on things like the notes of every meeting, employee relationships, back-channel drama, security discussions, etc. and how these things relate to corporate and technical assets, all contained in a single artifact/tarball, really ups the ante for what kind of "security hardening" you'd need for this.

Even exfiltration of API access for a few well-prompted queries could be really bad.

Yep for sure. Loads to consider here! My initial comment was just a brainstorm /bluesky thinking kind of idea. Clearly the implications are incredibly deep for security, data retention and a host of other concerns.

Presumably threat actors can already feed stolen document dumps to LLMs to quickly find interesting data.

OP mentioned meeting notes (like otter.ai) and other ephemera. I think that really changes the risk profile.

As someone who has spent far too much time diving into old Slack threads to unearth what happened in the past, I can see incredible value in a capability like this.

On the other hand, I think many companies would hesitate to create lasting records of written communications that go beyond the company’s retention policy.

While it’d be extremely useful, I think it would also increase potential liability that is currently managed by purge policies.

An excellent point around data retention and training data. It's not like you can scrub out bits of the neural network weights. I guess such a product would have to factor this in.

You kind of can right, isn't that essentially fine-tuning or reinforcement learning? I.e. if you told it to 'forget about the July 2019 fraud we did' to adjust responses going forwards accordingly?

Granted you'd have to test it without recording that, and you'd never really know for sure if you'd fully scrubbed it, only that you hadn't found a trace of it with your subsequent queries. ...now that I say that I'm sure there's a film about roughly this, delving into an AI trying to retrieve something hidden or something? The Wargames sequel perhaps?

Perhaps? I'm an LLM / NN layperson so I know basically zero. In my mind, the data is all smashed into a trillion numbers so there's no notion way of removing it as such.

Your point about fine-tuning it out is interesting though. As you say though, you'd have to be really sure you'd really erased it or made it "unreachable" .

An oracle that doesn't tell you when it doesn't know something, and lies or hallucinates answers instead?

Ha yes! We're not there yet with this tech, that's for sure.

Zoom offers this today! I think Zoom + a custom GPT could do the trick.

I only once saw proper „knowledge“ documentation working in a german company which had a strict waterfall methodology. When project started, we spent at least 1/3 of the time writing documentation and specification first, then code. Onboarding was a breeze and when corona hit - nothing has changed, we could operate as usual too. I also had to overtake a domain of another engineer who was leaving, the handover was minimal, as everything was written down.

> 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.

The US Army has formal training about this and provides an Advanced Skill Identifier (ASI) to those training to practice it. See:

* Techniques for Effective Knowledge Management, ATP 6-01.1, https://armypubs.army.mil/epubs/DR_pubs/DR_a/pdf/web/atp6_01...

The Army technique follows the DIKW model. https://en.wikipedia.org/wiki/DIKW_pyramid

When I did that job as NCOIC for a major sustainment command in Afghanistan I learned how to mix documentation, automation, and empathy to create a shared vision amongst the 24 shops that comprised the unit. I never would have matured into this writing corporate software.

Since being laid off this year I am choosing to regress and aggressively embrace tacit knowledge. In the past I used to publish things I had learned to GitHub and many people found those writing extremely beneficial. As a JavaScript developer, however, I have finally been beaten into submission by the neglectful immaturity of my profession and so many of my peers.

I have grown tired of debasing myself when so many people are hostile to any concepts of helpful guidance. The name of the game is attain employment by writing the same framework glue over and over thereby pandering to the desires of the least competent and least employable of the workforce. Any deviation is met with hostility first and possibly curiosity later. As a result I abandoned that line of work until I found a career change and now keep my learning about automation, performance, and architecture to myself.

Speaking of tacit experience, I love watching YouTube videos made by professionals working in industries I’m just a rank amateur in.

One thing that occurred to me is that I’ll observe these people casually and repeatedly applying “methods of the art” without a second thought, but then spend the entire episode talking about some specific obscure issue they’re trying to solve.

In my mind these have equal difficulty — and in some sense they are equal! It’s just that professionals may have done basics so often they don’t even think about it any more. It’s become a habit, mere tacit knowledge.

Some random examples:

Correctly centering something in a lathe — done in incorrectly can lead to this: https://www.forbesadvocate.com.au/story/907281/faulty-oil-pi...

I can think of thousands of examples like that: tacit knowledge is the knowledge you gain when you do something many times a day. That doesn’t make it less important, less valuable, or more obvious to beginners.

Nice article and good points, but perhaps the author wasn't aware that "tacit knowledge" is a term already used for something else.

https://commoncog.com/the-tacit-knowledge-series/

Tacit knowledge is undocumentable because it's knowledge borne out of experience. It's tacit because articulating it would be too tedious, impractical, and most probably incomplete. Think learning to play a sport by simply watching videos or reading instructions. Michael Jordan famously explained that although all players are taught the same theory, there's a point in a veteran's career where they can read the game at a different level. Closer to programming, it's the reason we see more articles repudiating well packaged ideas, such as "Clean Code" (capitalization intended), as past beginners who bought into them, are becoming experienced enough to recognize them as leaky abstractions.

I find that "figuring it out on my own" takes a bit longer, but I learn a LOT of answers to alot of other things I didn't know I needed.

"If I walk into a bookstore and you help me find the book I'm looking for, then You've robbed me of the opportunity to find all the books I wasn't looking for" -- paraphrasing Neil Tyson

Public everything inside the company. No private rooms. Redirect questions in dms to rooms. Public docs for everything. Everyone with full access to Google drive.

Now your "question to the other side of the world" becomes a slack search, or a docs search, and is even better than in person.

I think it is good to start by defining the concept because I first hear about "tacit knowledge" in the context of knowledge management [1]. In that context tacit knowledge is inherent to social systems. It is something that exists and could not be prevented.

At the end what the author should criticize is not the tacit knowledge but how the organization manages the knowledge. And that is, knowledge management.

[1] https://en.wikipedia.org/wiki/Knowledge_management

Tacit knowledge is inevitable. Some people, like Turing Award winner Peter Naur, claim that the knowledge in the programmer's head is actually the main "product" of programming. He calls this "Theory Building". There's an excellent paper on it, but it's pretty verbose, here's [1] a summary with some additional case studies.

[1] https://hiringengineersbook.com/post/autonomy/

Sometimes it's best to get answers from the horses mouth - meaning the resident expert. This is ideally the person who created a thing, but can also be the person currently responsible. If no such person even exists for critical infrastructure, your company is IMO in trouble.

Yes, documentation is important and should be kept up to date. People should consult documentation, and update it if it turn out to be old. But real, up to date, or deep understanding does not exist outside of human brains.

Intelligent people understand that knowledge can not ever be dangerous, because it's the human who makes things dangerous.

Intelligent people understand that when lesser intelligent people call knowledge dangerous, they will eventually, but definitely inevitably, ask for the banning of said knowledge, because "the evil knowledge makes people do things they shouldn't", or a variation thereof.

The place I've just joined has an extremely big problem with this. There's a lot of documentation, but it all relies on an immense amount of background knowledge to be useful. It's difficult to strike a balance between excessive detail in docs versus wide readership, but I'm inclined to prefer the former as it helps alleviate situations like this.

There is hard knowledge and there is tacit knowledge. It’s not black and white. It’s a continuum.

Tacit knowledge documentation can take form of pro tips, best practices, anecdotes, postmortems, retrospectives, values, and philosophy statements.

It’s possible to capture a bit of it in written form. It will never be fully documented. A little goes a long way though.

One easy and very useful habit we have where I work is to post all questions (even the stupidest questions) in public slack channels. That's also where most technical conversations happen. This helps us to hide less information in private chats.

I agree with this, but I also mourn the loss of "just talk to someone 20 ft away." The better the docs get, the worse the social ties get. And that's coming from someone who was nearly useless from distraction in an open office.

Scaling organizations requires work organizing the information about how things work. Tacit knowledge allows you to get stuff done with small groups without having to pay the extra cost of investing in organization.

Even if you could express all tacit knowledge, which yoy can't because you may not know you hold it or it's hollistic, sharing it takes and resources.

And no projects have an infinite amount of those, so choices are made.

I really dislike when companies represent their knowledge bases as a list of videos. I have seen it a few times and I look forward to videos becoming searchable more easily over time.

Please leave clues as close to the scene of the crime as possible. You can't fix everything, and some fixes are too big and take a long time, but please just leave me a clue.

Some tacit knowledge maybe is impossible to document, but in a lot of circles there is a distinct lack of ability by those who are skilled in some activity to describe how they do things. There is often a split between those who can execute at a world-class level, and those who aren't as good but can teach others effectively. I've seen this dynamic play out in competitive videogames, figure skating, musicianship, etc.

Take figure skating for example. I was being taught how to do a basic two foot spin by someone I know who is/was a competitive figure skater. Not a complicated move. They completely failed to explain to me a critical part of how to do the spin effectively (namely, where on my blades I should keep my balance and how I should angle them). So did several instructors leading classes on figure skating. I floundered for a while until one day I managed to figure it out by random chance.

I was quite annoyed, because to me it is a perfectly explainable thing that everyone was apparently either just figuring out through trial and error or just didn't think was worth explaining. But these kinds of pedagogical "blind spots" pervade nearly all human fields of study.

It can also be lucrative: witness Joe Flacco, who three weeks ago was sitting on his couch watching games on TV, now with a chance to lead the Cleveland Browns to the playoffs.

No knowledge can be fully explained in words

Does this mean tacit knowledge only exists within in-person teams? So projects like the Linux kernel don't have any tacit knowledge?

There’s less knowledge needed to manage these systems than we want to believe.

Tech is mired in hustle culture, which means it’s generating a lot of useless “knowledge” to role-play hustle.

Over engineering re-engineering to justify business headcount, importance, and prestige is a bigger danger in tech than the one this article points out

Reply on news.ycombinator.com