Tacit knowledge is more important than deliberate practice
commoncog.com
commoncog.com
The basic idea is this:
1. Deliberate practice only works for skills with a history of good pedagogical development. If no such pedagogical development exists, you can’t do DP. Source: read Peak, or any of Ericsson’s original papers. Don’t read third party or popsci accounts of DP.
2. Once you realise this, then the next question you should ask is how can you learn effectively in a skill domain where no good pedagogical development exists? Well, it turns out a) the US military wanted answers to exactly this question, and b) a good subsection of the expertise research community wondered exactly the same thing.
3. The trick is this: use cognitive task analysis to extract tacit knowledge from the heads of existing experts. These experts built their expertise through trial and error and luck, not DP. But you can extract their knowledge as a shortcut. After this, you use the extracted tacit knowledge to create a case library of simulations. Sort the simulations according to difficulty to use as training programs. Don’t bother with DP — the pedagogical development necessary for DP to be successful simply takes too long.
Broadly speaking, DP and tacit knowledge extraction represent two different takes on expertise acquisition. For an overview of this, read the Oxford Handbook of Expertise and compare against the Cambridge Handbook of Expertise. The former represents the tacit knowledge extraction approach; the latter represents the DP approach. Both are legitimate approaches, but one is more tractable when you find yourself in a domain with underdeveloped training methods (like most of the skill domains necessary for success in one’s career).
I think, by applying some of the core principles (variety of scenarios, high difficulty, guidance from expert available, high density of lessons, etc) I can learn things quicker, as well as help others learn things quicker. Even without CTA proper, which is its own skill I haven't taken the time to learn yet.
The future is here, it’s just not evenly distributed.
About half of the things I used to obsess about fifteen years ago are now common if not dogma. I don’t obsessively track the things that don’t pan out but odds are I was dead wrong about a few of them. Still waiting on the rest.
https://3starlearningexperiences.wordpress.com/tag/accelerat...
I've read Cognitive Load Theory by Sweller et al., and while a good book, it's not very practically oriented.
[0] https://www.amazon.com/How-Wish-Taught-Maths-conversations-e...
The article you link to is essentially a response to 2 pages in the book, where Hoffman et al mention, almost in passing, that CLT is a silly theory when you want to train for real world scenarios (the intuition is that if you’re training marine fire squad commanders to plan on the battlefield, perhaps it helps to simulate shooting at them during training?) Hoffman et al use this as an example of a learning theory that doesn’t seem to map to real world requirements.
This reads like a disagreement over one particular dismissal in the book, perhaps because CLT is a pet theory of the article’s authors. The problem: this argument is not core to the book!
The article does not, for instance,
a) Deal with the many examples of successful real world accelerated training programs with no curriculum design (as is commonly understood; ordering of simulations isn’t really designing a syllabus) in Chapter 9 (some of which were designed by some of the authors)
b) Have a rejoinder to the two learning theories presented in Chapter 11 that the authors claim underpins their training approach (if there were something to attack, this would be it!)
c) Nor have a rejoinder to a more central claim in the book, (and to my mind a more controversial claim) that atomisation of concepts impedes rapidised training.
And, perhaps most surprisingly to me, your claim that
> Reading it I got the distinct impression that the authors did not understand a great deal of the research they cited, either when supporting or dismissing it.
is remarkable, given that one of the authors of Accelerated Expertise is Paul J Feltovich, one of the founders of the field of expertise research, and a contemporary of Ericsson’s.
This has been my personal experience as well, and it makes me highly suspicious of anyone whose advice for acquiring technical skills is simply to practice constantly - "draw every day," "you have to code," "always be networking," etc. They either aren't aware of how useless this advice is, or simply don't care about your growth or performance. Which, I admit ambivalently, is reasonable in this society; if you want someone to care, pay them to. This of course opens us back up to the issue of underrepresented groups often being unable to afford formal "someone caring about your growth."
I will add though, some fields are far more open than others. Most notable would probably be software or computing in general. An observant person can glean insights from places like HN, Reddit, lobste.rs, GitHub/Lab threads, university course pages from all over the world, personal opinionated blogs, etc. etc. (add reading good open source code to this list too). I say observant because you need to sift through marketing (mostly HN and Reddit), influencer crap [0], (often attractive) polemics, etc. With computing, these places can come from genuine passion and respect for the craft, rather than grift like you'd find on LinkedIn [1]. From there a person can weigh up different ideas and experiences, looks for patterns, try to determine what is being implied and what context has gone unsaid, what is taken for granted, etc. This would replace otherwise unavailable mentors.
Like you, what you mention has been my personal experience. My experience with people from my demographic is that some, without formal guidance, struggle, and in getting started really need someone to hold their hand. In some cases this would be a problem of confidence and self-esteem more than ability. Others can soldier through looking to pick up bits of wisdom from wherever, eventually being able to make judgements of their own.
>and it makes me highly suspicious of anyone whose advice for acquiring technical skills is simply to practice constantly - "draw every day," "you have to code," "always be networking," etc.
It's a matter of perspective I think. This reminds me of that Ira Glass quote on taste and creativity. Perhaps taste is a sort of tacit knowledge, and this is picked up from mentors, or developed independently like I mentioned above. Then a person who does not know the experience of lacking taste -- either because they have access to mentorship (and took it for granted) or because they had the confidence and ability to independently "seek" tacit knowledge (and took the confidence and ability to actually do so for granted) -- lacks perspective and gives this advice. It "worked" for them, but really this is just the apparent, and they cannot express how they developed the taste or tacit knowledge (or that it is necessary!) for this advice to be useful.
[0] I specifically left YouTube off that list. Aside from conference videos posted to YouTube (hardly any views), university lecture recordings (hardly any views past first year with a few exceptions), and maybe a feeew other channels, YouTube content is in my experience garbage and very typical-influencer, mostly hyping up megacorps, the latest buzzword-tech, and grinding leetcode.
[1] Yes computing grift is very real, but I mean that it appears that sharing information online for "nobler" reasons or genuine professional reasons is more common in computing than in some other fields.
1. Be self-aware
2. Extract case library of simulations from yourself
3. Write a book covering the case library
Judgement is basically knowing a bunch of things but having a good idea of which things are more important than others, and especially knowing which things are worth spending time on any which aren't.
It's like when I see someone talking about financial options and they put everything on the board at once: what are puts and calls, what's an iron butterfly and other strategies, do they need to know the payoff diagram, what about black scholes, what are the Greeks, when should I exercise, and so on. They are all things that a professional option trader knows, but when you're a pro you reduce your cognitive load because you know what actually matters and you are not juggling all these concepts at the same time.
It's also the source of frustration when interviewing. Say you've written CPP for many years, you're probably not prepared to answer questions on all corners of the language, even though you're an expert in some sense. Someone relatively newer might be better at that task, because they're thinking a lot about everything, including things they haven't decided are unimportant yet.
I had an aha moment a little while ago when I realized "justify-content" works like the "justify" buttons in Google Docs/other word processors -- left/center/right. It's not a perfect parallel, since justify-content changes its meaning if the flex-direction changes, but it matches with the default behavior.
Oddly, my first specialty was performance optimization. A predisposition met a trouble project and I spent half my time finding ways to speed up code without making it offensive. Then later projects had problems but no mandate, so I got pushback. I got really good at crypto-optimization - changes that improve performance but look like something else (cleanup, bug fixes, feature requests), and found there’s a whole quadrant of code changes that answer both legibility and speed.
There is very little magic or intuition based about any of this. It could be in a book. If anyone knows of a book that covers this, I’d love to gift it to people, because as far as I’m aware I’m seen as a weird (semiretired) street preacher on this subject. But I’m just tweaking existing recipes as it were, adding common ingredients in uncommon ways.
Those teams built up that kind of tacit knowledge like in this video about software texture mapping https://youtube.com/watch?v=xn76r0JxqNM
Or better yet, how about just writing a series of blog posts or a newsletter?
Don't waste time on the setup, just register something on substack.com and I'm sure a bunch of folks here will subscribe. It sounds like a fascinating subject.
If I were to teach, which I kinda do as a leader of the team, I d just give a few shortcut: 99% of perf issues are stupid and discoverable by profiling (which nobody does somehow, the most experienced the least likely the dev will use a profiler and the most likely he ll have 50 wrong migration ideas to make everything better with a huge budget), once you compressed all leaves of code you can find on a hot path, look at why this hot path even exist, chances are it shouldnt even be called as often, if you did that and are still too slow, redesign, multi thread more, remove business need, expand the hardware.
You start also getting an instinct on scale: a troubled team behind by half an hour on a settlement process with an exchange, so big deal, told me they wanted to move the cloud to spin up hundreds of big server with a new scalable design that would take a year to develop with 0 skill in the team yet. How many operation do they need to do in the alloted time ? 30k, with a database on the back. Well, I havent looked yet, but this sounds to me like we can try something before the mega migration lol because 30k units of work is not much and databases tend to be misused (I once fixed a million statement sent by hibernate on a SOAP call, so...) but as you see I try not to give an explanation, it s just an instinct, because prejudice is what kills perf optimization: we'll have to profile each step.
One thing I try to teach is: never migrate to a new library while calling the slow code legacy: you'll end up either failing exactly the same way or fake-suceeding on a small sample and leave the actual failure to the next team who'll call your code legacy before moving to the next fancy fad framework of the year and start the cycle of disaster over again.
I've also removed a lot of 10% calls that improved performance by 20%. Profilers don't show the cost of your code to the CPU and Virtual Memory caches. And there are new or malloc calls whose full cost is paid by another thread due to the tempo of the allocations.
As you say, looking at the count column is a huge thing. But the biggest failure I've seen is one of imagination. So many people give up when the last tall tent pole has been addressed. Even if we've only hit a 3rd of our performance goal, they believe they've tried everything and we should move on. Nobody knows how to do perf analysis with a budget. For instance, the 'current users' count should not be entitled to 10% of the page load time.
Compare the rules around speed limits, don’t drive above 70mph (no judgement, could be too slow or too quick in a given situation) vs the one often observed and followed in reality, drive at a reasonable speed, roughly what others are driving at (use your judgement about what’s safe).
But judgement is a type of tacit knowledge.
Judgement is exactly the opposite of tacit knowledge.
... Which is fine if you've got an application in mind, but otherwise, they're a distorted view on the concepts to fit a specific implementation.
Most of those concepts are all describing, "when do you tell somebody where to point?" and "when do you follow the arrows?"
They have no explanatory power, they only flag the absence of a complete explanation: specially, the inability at present to break down and reproduce the process that generated the correct behavior.
They should not be revered for their superiority, but scrutinized for the true source of power they draw from.
They share similar concepts but judgement is more final, definitive, decisive in nature whereas discernment is comparatively flexible.
So I read the book he quoted - "Source of Power". And you know what? It has a tremendous overlap with Deliberate Practice.
The proponents of Deliberate Practice never claim to "just do it over and over" - you have to have background knowledge, a teacher/coach, etc... the tacit knowledge. Part of it is given to you and part of it is something that you're put into a position to experience for yourself.
It seems the "divide" is overstated.
The combination of tacit knowledge with deliberate practice is especially powerful, even more so when augmented by working smart, in addition to working hard rather than instead of working hard.
Leveraged furthest when applied to a foundation of natural unfair advantage of some kind or another.
Over the longest lifetime you can muster.
I'll assume the best in the author, that he simply interpreted deliberate practice differently than I did such that it was not useful for most things, and now he's trying to share the method that worked for him. But to me this is exactly what I would expect from deliberate practice.
And it left me with a similar feeling: the author suggests that acquiring tacit knowledge is more important than deliberate practice, when in fact deliberate practice is the most effective way to acquire tacit knowledge.
In the bicycle example, that would mean trying out different approaches, figuring out what works and what doesn't, and working with a coach (parent) to practice more effectively.
So, pitting these concepts against one another seems wrong, but keeping tacit knowledge in mind when applying deliberate practice might make it more efficient.
Ty Tashiro writes about how "awkward" people
https://www.ted.com/talks/ty_tashiro_why_we_re_socially_awkw...
need things to be spelled out and made explicit. With that, we can function as well as anyone. Without that we suffer when we get advice like "be yourself", "read Dale Carnegie", etc.
Ty was lucky to have parents that understood that he needed this and made sure he got it. I didn't. Often it would take me a while to get what came naturally to the other kids and adults never seemed to recognize that, which made me feel really lonely.
As an awkward person myself this certainly rings a bell. But for me it's more about getting permission. Growing up in an abusive household, everything that I did was like walking in an open minefield. You're running and doing things intuitively and everything seems normal until you're hit with an explosion of verbal and sometimes physical abuse.
Clearly unspeakable knowledge is a subset of unspoken knowledge, but there is definitely unspoken knowledge that is speakable if we take the effort to make it explicit.
"things awkward people need spelled out" is a great example of tacit knowledge that is often speakable (but we don't bother because the tacit assumption is that the tacit knowledge is shared by all.)
By conflating the unspoken with the unspeakable, the author fails to realize that a great deal of our tacit knowledge can be made explicit or at least partially explicit (and the value that can be captured by finding new ways to explicate the formerly unspeakable.)
In other words the unspoken knowledge can be learned from two sides, not one. It's understandable that the author focuses on their side, but I don't think he does so with the intention to discourage "the effort to make [the knownledge] explicit".
> My take on this is that it is so difficult that we shouldn’t even bother; assuming that you are reading this because you want to get good in your career, you should give up on turning tacit knowledge into explicit knowledge and just go after tacit knowledge itself.
> Why do we know this? > [What many researchers found out] was that it is extremely difficult to encode all the possible branches and gotchas and nuances from a human expert into an expert system.
To me that sounds like a direct analog to "nobody will ever understanding everything about the source code without reading it, so we shouldn't bother with documentation".
Obviously we can't / shouldn't document everything, but creating documentation as you learn an undocumented legacy code base can be of great value (as can asking other developers to explicate their implicit knowledge).
Over and over the Author ignores the unexplicated but explicable and assumes that implicit knowledge is inexplicable.
I don't think the guy is any sort of "certified expert" but it rings true to me. And occasionally I've tried to give people related advice but found I couldn't. For example: How do you know when you you're close enough with someone that you tease them in a way that they'll take well vs badly? I'm pretty good at knowing it, but I'll be damned if I can explain it.
tl;dr of the article is that when people are learning then explicit rules and guidelines are helpful. Once you get better at it, they are unnecessary and even harmful. People in the latter stage tend to give crappy advice like "just be yourself" because it works for them now, they don't really exactly know what they're doing (ie, the knowledge is implicit) and they've forgotten what it's like to be totally incompetent.
Anyway, perhaps the point is that while it's difficult to externalize how to "not be awkward" (and indeed it would likely be different for every social group) you can probably use rules to get along well enough, for long enough, to figure it out the hard way.
The most useless advise in history, closely followed by "just stop being depressed"
"On second thought," the savvy adept said, "Strive to become the person you wish you were and hope that people will like who that is."
I've grown to appreciate such useless advice. It is useless in answering the question you wanted help with but it is a strong signal that you can prune the person who gave such advice out of your social graph without any negative repercussions.
It seems reasonable to argue that if they are indeed in your social graph and they give you that advice, perhaps they like you for who you are and thus the advice at least from their perspective is good.
No substantive evidence exists suggesting Einstein made this statement...QI [quote investigator] has identified an influential essay called “An Educational Allegory” that was written under the pen name “Aesop, Jr.” and published in the “Journal of Education” in 1898. The author was later identified as Amos E. Dolbear of Tufts, a prominent physicist and inventor. The essay emphasized the absurdity of using a single inflexible standard for assessing the achievement of each individual student.
Here are other examples I can think of:
- Learning programming in the first place. Many people struggle.
- Teaching rhythm to an older adult with no musical experience.
- Ear training. No explanation will substitute for practice.
This isn't to say that explanations never work and you shouldn't try, but rather their hit rate may be lower than you think, that coming up with the right exercises might work better, and that beta testing your work is important.
I developed it with a professor at UMich to teach a data science course for non-CS grad students. He had a deep belief in tinkering, exploration, and one-step-at-a-time learning. And I’ve seen it work pretty well. Pathbird itself is a platform for instructors to build these kinds of computational, “guided” lessons that emphasize the experience and process of learning.
Far too many intro CS/programming lessons read like glossaries. Obviously the syntax of if statements and for loops is important, but starting there on day one encourages students to miss the forest for the trees.
I don't see any link in the "(free) spin!" section, and even after registering I'm not seeing any way to demo a course.
Lil help?
For ear training, I’ve read that singing helps, since it associates vocals with pitches. I’ve tried ear training programs and even wrote one, and it’s the sort of thing where you get better by practicing a little a day. Doing a lot of practice at once is just frustrating. I was doing better for a while, but stopped practicing and wouldn’t say my ear is all that good.
Recently I’ve been transcribing music, which probably helps some. It’s sort of like figuring out a crossword puzzle where it takes a few guesses to get the notes right.
For ear training, you need to practice interval recognition, chord recognition, transcribing melodies, transcribing chord progressions, etc. And _also_ you should be doing a lot of singing, especially sight singing. Again, you'll need someone more expert than you to tell you if you're getting it right in some cases. But if you're transcribing a piece that has sheet music you can get instant feedback. And the same goes for sight singing. Sing it, then play it on the piano and see if it sounds right. Better yet, _record_ yourself singing it and play along on the piano. If the all the notes are the same, you win.
The other thing you should be doing is actually playing music! Doing lots of exercises is great, but the whole point of this is to make you a better musician, not just someone who's really good at notating rhythms of the music they hear.
(Source: I have a master degree in music composition and I taught ear training and theory during grad school. Plus I also struggled quite a bit with ear training (but not rhythm) myself.)
Here's an example of programmer [interviewer] belief in transmissionism https://news.ycombinator.com/item?id=29410641
Of course if you have a great mentor so much better. But this reminds me of the medieval guild system. You had to be an apprentice, you had to be an intern for many years. The thing is, highly skilled people could make their main goal to teach others. But economically it makes more sense for them to use that skill themselves.
Therefore we can speculate that a lot of tacit knowledge remains tacit because those who posses it don't want to share it, without good compensation, like having an apprentice who works for them for many years.
Akin a podcast/interview. Where the whole purpose is for the interviewee to share his tacit knowledge.
Experts go and are asked questions about specific situations. Said questions are made in such a way to tease out the tacit knowledge. (using the critical decision method)
... The more I think about it the more I want it to exist. Anyone knows of something similar? Or is interested to create it? or just interested to have it exist?
* https://commoncog.com/blog/putting-mental-models-to-practice...
It is the same reason as you can't teach someone to play guitar by words without actually making them play and see the mistakes, even though you are perfectly capable to teach which area to press and how to strum and even make the person memorize the sequence.
As an additional corollary, the tacit knowledge concept is a good argument against decision frameworks generally, which destroy information by trying to capture experience in a rubric.
[0] Getting more out of experts by focusing on results and not process: observations of people and neural networks http://marble.onl/managing_ml.html
That said, I believe it is possible (and useful) to slowly extract parts of tacit knowledge into decision framework. Kind of "best practice" lists in respective fields. This will help new comers avoid past mistakes and use that time/cognitive capacity to push the boundary of knowledge/skill to uncharted territory. Otherwise we will be stuck in a status-quo.
Take chess. There are advises like don't play such-and-such a move in this position. If you follow the rabbit hole you'll see that hundreds of chess masters had played those lines to weaken their position. And later scores had analysed those games to codify it into "don't play foo in baaz middle game". Of course GMs sometimes go against those advises because they are GMs.
It's almost impossible to advance a field if we all relied on tacit knowledge alone. Because it doesn't scale and we'll spend all our cognitive capacity in repeatedly committing same mistakes.
As an expert in my field I repeatedly force myself to question the source of my judgement when someone asks me "why" when I say "this API doesn't look right". When I do so I indeed realise that it violates some foundational principle and explain it. An expert who can't describe the source of their wisdom, once in a while, end up getting stuck IMO. Because they are not exercising that deductive part of their brain and come to rely more and more on their "wisdom". Over time they fail to adopt to changing conditions and become dogmatic and less relevant.
Physicality and proximity are incredibly important, ironically maybe more so in the world of 'knowledge work' than when it comes to physical activity. An incredible amount of knowledge work happens implicitly when people organize spontaneously without them even being aware. Alex Pentland wrote an interesting book on it called Social Physics where he tried to empirically measure how much more effective in-person exchange of information is.
The 'Paypal Mafia' is I think a good example of this. It's hard to imagine you get the same number of businesses out of a dispersed, random groups on the internet. Business knowledge and success even in 'meritocratic' sectors are still depend on a lot of tacit and informal relationships.
The strategic choice of how and what to study is also part of a good deliberate practice regime (interrupted from time to time in programming by needing to cram leetcode for no good reason, because why would a company want to hire somebody who was an expert at making modular easy-to-change systems when there are these heaps everywhere that need to be written from scratch in 15 minutes?)
> Somebody serious about deliberate practice will spend a lot of time seeking “tacit knowledge.”
Putting words in the author's mouth, he's saying that tacit knowledge is more important in areas where (i) execution isn't clearly prescribed; to (ii) perform at a high level.
The author gets into how in certain fields, there's a "missing manual" and requires figuring it out yourself or undergoing an apprenticeship, prioritizing attainment of tacit knowledge.
Leetcoding is a "missing manual" expertise path and doesn't converge, IMHO, like chess, violin, athletics, etc.
However, what I did not expect was for the article to go into that Atul Gawande quote on the laparoscopic appendectomy. It just so happens that the MVP I’m building is part of a training program for laparoscopic skill and the other half of my job is making the actual educational content, including the appendectomy (I’m a jack-of-all-trades - we’re a tiny company). How strangely surprising!
I spend a lot of time testing our product with users, who all happen to be in surgical training. The professor of surgery with whom we collaborate, regularly brings up the kid/bicycle/teaching experience. Laparoscopic suturing is currently seen as an art form, and it’s a such a great example, so he usually just tells people to practice. In surgery more than in any other field everything is relative, mushy and tricky. You’re juggling manual instrument skill with medical knowledge, along with people skills (in the OR). Our approach has been to focus - with our products you only learn the skill but none of the other stuff.
I’m definitely saving this one, and going be exploring all the linked sources and materials. Thanks!
For example, to launch a new product we need the obvious end-user-visible features - but also sufficient back-office features to be able to quickly fix the inevitable problems that crop up. Things like adjusting a customer's account balance, say to give them a quick credit when something else goes wrong. Basic stuff right?
But management - this has happened to me - will often say something like "why are there going to be problems? Don't you know what you're doing?". And of course I do know what I'm doing, that's why I'm assuming something nobody has thought of is going to go wrong, and I'm trying to create a way to help us mitigate it without taking the lustre off the launch.
The problem as I see it is that management is often seen as a generic function of business with a translatable skill set, but in most cases they don't have the tacit knowledge they need to make good decisions in the domain they're supposedly managing.
Being able to turn this tacit knowledge into something consumable by others would be a huge boon to project management IMO.
In his book, Polanyi also uses the idea of tacit knowledge to tackle a question from Plato's famous Socratic dialogue, 'Meno': "can virtue be taught?"
You can find an excellent English translation of 'Meno' in Hackett's "Five Dialogues"[2] publication. A superb short book with a great selection of five short Platonic dialogues; reading it gives a richer picture of Polanyi's ideas. It[2] also serves as a great intro to Plato.
How can you compare a method of learning to a kind of knowledge? This comparison does not make sense at all.
There's also this chicken-and-egg problem: (1) you can't absorb the knowledge well because you haven't practiced (2) you can't practice well because you don't know a shit.
This early stage is really really painful.
Seniority is different from juniority in the ability to make things explicit as much as possible, from the requirements to the implementation specification.
I think in software engineering, the more explicit, the better.
Most people seem to believe their post hoc explanations. Or at least most people wont admit that they are post hoc explanations, it is hard to know the difference since they come up with those post hoc explanations with the intention to manipulate you. That is also the reason it is so hard to change peoples minds in an argument, they wont bring up the real reasons they believe stuff they just bring up the post hoc tings. People seem to think that exposing your real reasoning makes you vulnerable. Like yeah, you get vulnerable to learning new stuff and changing your opinion, that isn't so bad.
At the bottom Chin says what he thinks is the way to acquire tacit knowledge: apprenticeship. He should have called the article "Apprenticeship is more important than deliberate practice," which hinges on precisely what you mean by "apprenticeship" and "deliberate practice," either of which can be defined in ways to make the statement true or false.
- Pair programming?
- Informal interactions with leads?
- Study and emulate great works?
- Dabbling with intriguing works unrelated to our main project?
- Our own behavior (reflected tacit knowledge made explicit via personal software process)?
What I found works best is a ~50-50 combination of verbal explanation of important know-hows(bike moves where you are looking, don't stare at the speedometer/front fork, look through the turn) and preparing the student to learn the tacit component on their own (counter steering is spooky action at a distance, just make it feel right and pay attention to how the bike reacts to the movements of the body)
Perhaps I'm missing something here. But the hypothesis that tacit knowledge is more important than deliberate practice - without reference to the field we're talking about - is a bold claim. I know cognitively that the staccato of Mozart is qualitatively different than that of, say, Bartok. But that doesn't do anything until I develop the motor skill to make it so.
Now the engineer has an explanation of art but still no art.
Which is pretty much where we started.
I don't think explaining is gonna cut it here.
In college, the team tried to teach us explicitly and it made absolutely no sense. By playing for years, I've developed the simple instruction of "Stand where you do not want or expect the disc to go, and at the right time, run to where you do want the disc to go."
The part that takes hundreds of hours is understanding "where you want the disc to go" and that can't be explained clearly because it changes every five seconds. After 10 years, the answer is usually obvious to me, but a new comer has absolutely no idea why anything is happening or why they are not getting thrown to.
Maybe the difference could be explained with racecar driving. Driving the track correctly, hitting apexes, downshifting at the right moment; that's deliberate practice.
Knowing your car, understanding what a particular vibration means, feeling when you're approaching your traction limit, knowing that your engine is weak from 4-5k RPM, that's tacit knowledge.
Deliberate practice can foster tacit knowledge, however. Going through the motions opens your mind up to understanding what's going on behind the relatively simple task you're performing.
... but isn't that is pretty much what "deliberate practice" prescribes? Practice a lot at the edge of competence (or just over it). It just doesn't explicitly say "to gain tacit knowledge".
As for other stuff, simulators?
I mean, obviously you can explain many things to someone who can't replicate it "just in time", riding a bike is one of those examples.
Explain math, playing guitar, reading, or whatever perfectly to a person, they still have to practice to be able to do it.
The problem isn't the explanation, it's the difficulty of the skill to learn.
Don't know why we need a new word/phrase for it.
It would take time, of course, and a lot of practice rather than just having it explained to you. But I don't see why it wouldn't be trainable.
However, should a day come when a new method circumvents this very crude way of knowledge transmission, this debate will be significantly changed or even rendered moot.
Milan, 1496: "Hey Leonardo, I really like your last supper, great work. Oh, and hey by the way, your assement of the new company was awesome"