[HN Gopher] Tacit Knowledge Is Dangerous
___________________________________________________________________
Tacit Knowledge Is Dangerous
Author : Wingy
Score : 109 points
Date : 2023-12-12 16:17 UTC (6 hours ago)
(HTM) web link (er4hn.info)
(TXT) w3m dump (er4hn.info)
| vt100 wrote:
| Does this mean tacit knowledge only exists within in-person
| teams? So projects like the Linux kernel don't have any tacit
| knowledge?
| MarkusQ wrote:
| 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.
| haltist wrote:
| This is very much like my panoptic computronium cathedral(tm).
| 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.
| peteradio wrote:
| Surely I wouldn't need to ingest anything to monitor my
| bowels, mightnt I simply insert a device up my ass?
| haltist wrote:
| Intriguing possibility.
| thfuran wrote:
| It's more robust to have multiple modalities, so you really
| ought to do both.
| pavel_lishin wrote:
| A loremaster who will lie when they don't know the answer
| instead of saying, "I don't know".
| ycombinete wrote:
| At which point it becomes the Dungeon Master
| pavel_lishin wrote:
| 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."
| DaveSchmindel wrote:
| 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.
| FeepingCreature wrote:
| 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.
| jmfldn wrote:
| 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.
| ericbarrett wrote:
| Such an oracle would be a devastating thing to lose to
| industrial espionage.
| jmfldn wrote:
| 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.
| ericbarrett wrote:
| 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.
| jmfldn wrote:
| 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.
| plugin-baby wrote:
| Presumably threat actors can already feed stolen document
| dumps to LLMs to quickly find interesting data.
| ericbarrett wrote:
| OP mentioned meeting notes (like otter.ai) and other
| ephemera. I think that really changes the risk profile.
| haswell wrote:
| 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.
| jmfldn wrote:
| 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.
| OJFord wrote:
| 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?
| jmfldn wrote:
| 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" .
| pavel_lishin wrote:
| An oracle that doesn't tell you when it doesn't know something,
| and lies or hallucinates answers instead?
| jmfldn wrote:
| Ha yes! We're not there yet with this tech, that's for sure.
| DaveSchmindel wrote:
| Zoom offers this today! I think Zoom + a custom GPT could do
| the trick.
| phkahler wrote:
| 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.
| ChrisMarshallNY wrote:
| 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.
| botalert wrote:
| 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.
| Swizec wrote:
| > 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.
| travisjungroth wrote:
| 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".
| er4hn wrote:
| 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.
| travisjungroth wrote:
| 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?
| datadrivenangel wrote:
| 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.
| tikhonj wrote:
| 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.
| fidotron wrote:
| 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".
| pheres wrote:
| 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.
| geodel wrote:
| 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.
| justin_oaks wrote:
| 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.
| peteradio wrote:
| 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.
| nonrandomstring wrote:
| 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.
| pixl97 wrote:
| 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.
| nullhole wrote:
| 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.
| betenoire wrote:
| 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.
| tikhonj wrote:
| 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.
| jessriedel wrote:
| Thanks, this is the exactly correct critique of the article.
|
| I'll just add that the author did not seriously grapple with
| the fact that leaving at least _some_ explicit knowledge
| undocumented is inevitable. There is no sharp divide between
| "explicit knowledge every programmer should know" and "explicit
| knowledge that only makes sense in our organization".
| Documenting is costly to produce, and documentation is costly
| to maintain even after it is produced. (If nothing else, more
| documentation makes it harder to search.) This holds even if
| it's simultaneously true that large organizations usually
| document insufficiently because of laziness and bad incentives.
| er4hn wrote:
| I agree that some is inevitable, but as that amount increases
| it will provide a drag in what the organization is able to
| accomplish. This becomes even worse as an organization is
| remote locally and globally spread out.
| k_process wrote:
| 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.
| chongli wrote:
| 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.
| panarky wrote:
| _> > 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.
| mnsc wrote:
| 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.
| aleph_minus_one wrote:
| > 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.
| chongli wrote:
| 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.
| nyrikki wrote:
| 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.
| chongli wrote:
| _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
| nyrikki wrote:
| 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.
| nyrikki wrote:
| 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...
| deathanatos wrote:
| > _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.)
| Izkata wrote:
| > 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.
| quacked wrote:
| > 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?
| nyrikki wrote:
| 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.
| athanagor2 wrote:
| > Mathematics, especially, seems to have a strong tacit
| component.
|
| It's quantifiers, and bound and free variables.
| CrypticShift wrote:
| 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.
| Lutger wrote:
| 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.
| ekidd wrote:
| > _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.
| enasterosophes wrote:
| 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.
| smilliken wrote:
| 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.
| AnimalMuppet wrote:
| Um, can I retract about the last 15 years of my advice?
| vishnugupta wrote:
| +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/
| denial wrote:
| 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.
| hoherd wrote:
| 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.
| sonicanatidae wrote:
| 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.
| jsty wrote:
| 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.
| lucidguppy wrote:
| 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).
| sonicanatidae wrote:
| That would be a good use of LLM AI, imo. Good idea.
| cratermoon wrote:
| > 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.
| rout39574 wrote:
| 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.
| pixl97 wrote:
| 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.
| williamdclt wrote:
| 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
| sonicanatidae wrote:
| 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. :)
| j45 wrote:
| 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.
| sonicanatidae wrote:
| 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. ;)
| krisoft wrote:
| > 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".
| sonicanatidae wrote:
| 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
| PH95VuimJjqBqy wrote:
| 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.
| j45 wrote:
| 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.
| breischl wrote:
| 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.
| justin_oaks wrote:
| 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.
| citrin_ru wrote:
| 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.
| artemonster wrote:
| 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.
| matt3210 wrote:
| 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
| antoineMoPa wrote:
| 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.
| bookofjoe wrote:
| 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.
| cloogshicer wrote:
| 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/
| rodrigosetti wrote:
| No knowledge can be fully explained in words
| wslh wrote:
| 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
| austin-cheney wrote:
| 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.
| PakG1 wrote:
| 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.
| er4hn wrote:
| 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.
| vasco wrote:
| 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.
| BiteCode_dev wrote:
| 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.
| mmcgaha wrote:
| 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.
| surgical_fire wrote:
| > 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.
| stillwithit wrote:
| 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
| mekoka wrote:
| 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.
| 6gvONxR4sf7o wrote:
| 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.
| RadiozRadioz wrote:
| 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.
| csours wrote:
| 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.
| dgunay wrote:
| 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.
| jiggawatts wrote:
| 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.
___________________________________________________________________
(page generated 2023-12-12 23:01 UTC)