![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
elfsCommonplace has an interesting article called Expertise is Just Pattern Matching, in which he lays out an interesting thesis: that “expertise” is just having a very wide array of prototypical implementations of a knowledge base in your head, from which you can rapidly pick the “best” implementation from among many.
The problem with articles like this one is that it places a limit on the bounds of discussion without even realizing it, because it fails to distinguish between three very different kinds of expertise, and for want of better terms, let’s call them physical, mental, and emotional.
Commonplace’s article takes place is the world of mental expertise, that is, a kind of knowledge-based expertise where the hallmark of the skill set is the ability to stitch together a collection of mental models in your head into a working solution. Software developers understand this kind of model intrinsically; it’s literally what we do all day, and my current job is to teach other people how to acquire that knowledge.
Unfortunately for us programmers, the real answer to the question is “practice.” You can’t acquire that expertise through mere reading, you have to put the technique you’re acquiring through your fingers and your screen and see it, and do it, for yourself.
Other kinds of expertise, though, have different requirements. Commonplace’s pattern-matching notion doesn’t have much resonance in mastering a physical skill, such as the early parts of drawing, or playing a musical instrument, or even touch-typing. That’s virtuosity. Virtuosity isn’t the kind of knowledge that can be pattern-matched; it can only be mastered until one develops a sense of expressiveness.
The third kind is performance, the ability to take that expressiveness and, well, express yourself effectively. That’s when you take the physical skills and your knowledge of the piece to be played, and you turn those into a powerful expression of emotion and communication.
I’ve found this in my career. Right now, my career has taken me all the way back to Javascript, and I’ve been teaching (more like “showing off”) my virtuosity to the junior devs in my team. It took me about three weeks to take my knowledge of how languages like Haskell and Rust work, and apply them to Typescript, which is the language of choice.
I’m having to work hard on all three kinds at once. My expertise allows me to stitch together in my head a variety of end-to-end ways of implementing the solution. My virtuosity with my toolkit is fast and profound, so much so that my peers have asked me from time to time to explain what I’m doing because as one of the said, “As far as I can tell, that was an incantation.” And finally, I’m having to perform in front of them as a teacher, falling back on the pedagogical skills I’m still grateful CompuServe sprang for twenty years ago, giving me a chance to take classes on teaching so that I could help my then-co-workers do what I do.
On the other hand, I remain a Rust newbie; my skills with Rust have deteriorated badly as I’ve dealt with the pressures of the new job. I have neither expertise nor expressiveness in Rust, which is disappointing, but the demands of a full-time job and the pressures of the real world have kept me from fully diving into Rust the way I want.
When looking into a skill, you have to know which level you’re at. In drawing, I’m in the physical practice stage: acquiring expressiveness and virtuosity. In programming professionally, I’m in the performance stage of empirical programming; I just “do” what is necessary, and then restrain myself into creating a design document to justify the decisions my back-brain made almost automatically. And in programming recreationally, I’m in the expertise track: trying to learn the patterns that the theory-oriented programming world demand of me.
The important thing here is that these all take time, but they take different mind-sets to achieve. Acquiring the patterns of knowledge is time-consuming, but not very repetitive. Every lesson must be slightly different, to push out the borders of knowledge. Acquiring the patterns of virtuosity requires that the borders be pulled in, that your physical systems must be trained to do only and exactly what you want them to do, to avoid playing the bad note or striking the wrong key. And the patterns of performance require a third, and more painful, set of skills, because often performance requires that other people judge your work and give feedback.
All are worthwhile. But understanding which is which can help you choose the course of action when undertaking a new course of learning.
The problem with articles like this one is that it places a limit on the bounds of discussion without even realizing it, because it fails to distinguish between three very different kinds of expertise, and for want of better terms, let’s call them physical, mental, and emotional.
Commonplace’s article takes place is the world of mental expertise, that is, a kind of knowledge-based expertise where the hallmark of the skill set is the ability to stitch together a collection of mental models in your head into a working solution. Software developers understand this kind of model intrinsically; it’s literally what we do all day, and my current job is to teach other people how to acquire that knowledge.
Unfortunately for us programmers, the real answer to the question is “practice.” You can’t acquire that expertise through mere reading, you have to put the technique you’re acquiring through your fingers and your screen and see it, and do it, for yourself.
Other kinds of expertise, though, have different requirements. Commonplace’s pattern-matching notion doesn’t have much resonance in mastering a physical skill, such as the early parts of drawing, or playing a musical instrument, or even touch-typing. That’s virtuosity. Virtuosity isn’t the kind of knowledge that can be pattern-matched; it can only be mastered until one develops a sense of expressiveness.
The third kind is performance, the ability to take that expressiveness and, well, express yourself effectively. That’s when you take the physical skills and your knowledge of the piece to be played, and you turn those into a powerful expression of emotion and communication.
I’ve found this in my career. Right now, my career has taken me all the way back to Javascript, and I’ve been teaching (more like “showing off”) my virtuosity to the junior devs in my team. It took me about three weeks to take my knowledge of how languages like Haskell and Rust work, and apply them to Typescript, which is the language of choice.
I’m having to work hard on all three kinds at once. My expertise allows me to stitch together in my head a variety of end-to-end ways of implementing the solution. My virtuosity with my toolkit is fast and profound, so much so that my peers have asked me from time to time to explain what I’m doing because as one of the said, “As far as I can tell, that was an incantation.” And finally, I’m having to perform in front of them as a teacher, falling back on the pedagogical skills I’m still grateful CompuServe sprang for twenty years ago, giving me a chance to take classes on teaching so that I could help my then-co-workers do what I do.
On the other hand, I remain a Rust newbie; my skills with Rust have deteriorated badly as I’ve dealt with the pressures of the new job. I have neither expertise nor expressiveness in Rust, which is disappointing, but the demands of a full-time job and the pressures of the real world have kept me from fully diving into Rust the way I want.
When looking into a skill, you have to know which level you’re at. In drawing, I’m in the physical practice stage: acquiring expressiveness and virtuosity. In programming professionally, I’m in the performance stage of empirical programming; I just “do” what is necessary, and then restrain myself into creating a design document to justify the decisions my back-brain made almost automatically. And in programming recreationally, I’m in the expertise track: trying to learn the patterns that the theory-oriented programming world demand of me.
The important thing here is that these all take time, but they take different mind-sets to achieve. Acquiring the patterns of knowledge is time-consuming, but not very repetitive. Every lesson must be slightly different, to push out the borders of knowledge. Acquiring the patterns of virtuosity requires that the borders be pulled in, that your physical systems must be trained to do only and exactly what you want them to do, to avoid playing the bad note or striking the wrong key. And the patterns of performance require a third, and more painful, set of skills, because often performance requires that other people judge your work and give feedback.
All are worthwhile. But understanding which is which can help you choose the course of action when undertaking a new course of learning.
