I think it’s also useful to clarify the relevant meaning of “fluency” in a technical topic, so that we can talk about fluency in smaller topics and work the ratchet of getting more and more stuff towards “have skill”, without juggling too much at once in the “learning” state and forgetting things before they are fixed.
The relevant sense of fluency is not about speed or quality of results or diffculty of the problems that can be solved, even though these things come with fluency, but about skill at answering most simple questions and performing recurrent tasks that’s mostly offloaded to System 1, that’s intuitive and doesn’t require too much attention to keep going. Solving simple problems has to become easy. Even if you can solve hard problems perfectly and quickly using a method novel to you that was just explained, that’s not yet fluency, because you’d be leaning on attention and working memory. If you commit those same capabilities as System 1 skills, they would do most of the work for you while leaving enough attention to plan the process, and won’t be forgotten in a year, allowing accumulation of vast expertise. Compare this practice with learning a topic just well enough to become capable of solving some problems (cramming for an exam is an important example of this failure mode).
Things one can become fluent at can be as small as seeing the structure and motivation for a solution to a particular (kind of) exercise or to a standard lemma. As skills add up, knowledge of how particular words translate becomes ability to speak a new language. This never happens if you keep relying on a combination of working memory and a dictionary.
Right, I agree. Being able to answer simple questions almost instantly, without even having to think through it consciously, is a good indication of the System 1 at work, which is the goal (or maybe the definition) of learning a skill. Some programs and tests are deliberately structured in this way. The Kumon program is one.
I think it’s also useful to clarify the relevant meaning of “fluency” in a technical topic, so that we can talk about fluency in smaller topics and work the ratchet of getting more and more stuff towards “have skill”, without juggling too much at once in the “learning” state and forgetting things before they are fixed.
The relevant sense of fluency is not about speed or quality of results or diffculty of the problems that can be solved, even though these things come with fluency, but about skill at answering most simple questions and performing recurrent tasks that’s mostly offloaded to System 1, that’s intuitive and doesn’t require too much attention to keep going. Solving simple problems has to become easy. Even if you can solve hard problems perfectly and quickly using a method novel to you that was just explained, that’s not yet fluency, because you’d be leaning on attention and working memory. If you commit those same capabilities as System 1 skills, they would do most of the work for you while leaving enough attention to plan the process, and won’t be forgotten in a year, allowing accumulation of vast expertise. Compare this practice with learning a topic just well enough to become capable of solving some problems (cramming for an exam is an important example of this failure mode).
Things one can become fluent at can be as small as seeing the structure and motivation for a solution to a particular (kind of) exercise or to a standard lemma. As skills add up, knowledge of how particular words translate becomes ability to speak a new language. This never happens if you keep relying on a combination of working memory and a dictionary.
Right, I agree. Being able to answer simple questions almost instantly, without even having to think through it consciously, is a good indication of the System 1 at work, which is the goal (or maybe the definition) of learning a skill. Some programs and tests are deliberately structured in this way. The Kumon program is one.