Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tacit Knowledge Is Dangerous

er4hn.info

Post reply on HN
Print view View original

91–100 of 143 posts

Re: Tacit Knowledge Is Dangerous

#91

Post by athanagor2 »

chongli wrote: post #55
tikhonj wrote: 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…

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

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

It’s quantifiers, and bound and free variables.

Re: Tacit Knowledge Is Dangerous

#92

Post by nyrikki »

panarky wrote: post #78
chongli wrote: post #55

Earlier quoted context omitted.

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

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

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.

Re: Tacit Knowledge Is Dangerous

#93

Post by vishnugupta »

tikhonj wrote: 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…

+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/

Re: Tacit Knowledge Is Dangerous

#94

Post by chongli »

aleph_minus_one wrote: post #88
mnsc wrote: post #82

Earlier quoted context omitted.

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…

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

Re: Tacit Knowledge Is Dangerous

#95

Post by nyrikki »

nyrikki wrote: post #92
panarky wrote: post #78

Earlier quoted context omitted.

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

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…

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

Re: Tacit Knowledge Is Dangerous

#96

Post by pixl97 »

nonrandomstring wrote: post #45
tikhonj wrote: 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…

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 k…

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.

Re: Tacit Knowledge Is Dangerous

#97

Post by 6gvONxR4sf7o »

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.

Re: Tacit Knowledge Is Dangerous

#98

Post by enasterosophes »

ekidd wrote: post #71
tikhonj wrote: 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…

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

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.

Re: Tacit Knowledge Is Dangerous

#99

Post by pixl97 »

rout39574 wrote: post #38
sonicanatidae wrote: post #26

Earlier quoted context omitted.

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.

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.

Re: Tacit Knowledge Is Dangerous

#100

Post by smilliken »

ekidd wrote: post #71
tikhonj wrote: 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…

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

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