I like it. FWIW, I find this is exactly the same line that must be crossed to become an expert at many things. Some examples that come to mind, there are probably more I just don’t have enough experience with to be able to be sure they are examples:
programming
mathematics
writing
Things that seem like anti-examples, i.e. things that are not in this category with baking:
rock climbing (although there is a lot of skill involved, you don’t have to understand the gears to succeed, you can learn to intuitively make efficient motions that move you up without understanding too much about why or how that happens)
meditating (although lots of people get into the gears, plenty of people successfully meditate either without a deep understanding of what they’re doing or possibly actively mistaken theories that work anyway)
Again, I’m sure there are more, and I think for all of these there’s plenty of room to argue on the margins.
If I had to guess at what the divider is it’s something like how robust the ontological abstractions around the topic are at levels that matters for the task. The more robust, the less like baking, the more fragile and leaky, the more like baking.
To say a little more, programming is the thing that resonates for me most strongly with the above description of baking as not ritual. I notice it because there are lots of people who learn to program by ritual. They do well enough to get jobs and become my coworkers, but then they also write code full of cruft because they are programming by ritual rather than through deep understanding.
The classic examples of this that come to my mind are things like people thinking the iterator variable on a for loop must be named i or else it won’t work, or struggling with sed because they don’t realize they can pick the separator character on each invocation, or thinking they need [technology X] because they heard successful businesses use [technology X].
To add to this, I’ve noticed something that I do when I’m programming is rely on various constructs/built-ins that I have a solid gears-level model of. I often find myself unwilling to use functions/constructions where I don’t understand why they do what they do because I’m worried that the code might cause unintended effects that cause bugs, especially since debugging is extremely difficult without gears-level models.
I think the ideal programmer maintains probability distributions over whether or not they understand what various parts of their code is doing. If there is a bug, then they have some weighting over where the bug probably is, enabling faster debugging.
I’m in the midst of a career transition into computational biology. I taught myself coding at a young age and find it intuitive, but I’ve never worked in a tech job before. This reassured me that if people who don’t know that an iterator variable doesn’t need to be named “i” to work, that I can get a job in tech too, since I’m at least beyond that. Thanks :)
On the other hand, not knowing this might be like the 2-4-6 problem, where people just never thought to test this assumption. It would be entirely possible for a programming language to limit you to “i” (although nested loops would get weird). I wouldn’t call this a lack of conceptual knowledge, as much as one thing they haven’t tried. Having bad naming like this is bad [style](http://paulgraham.com/taste.html) , in my opinion, but doesn’t mean that whoever doing it must be a bad programmer.
I like it. FWIW, I find this is exactly the same line that must be crossed to become an expert at many things. Some examples that come to mind, there are probably more I just don’t have enough experience with to be able to be sure they are examples:
programming
mathematics
writing
Things that seem like anti-examples, i.e. things that are not in this category with baking:
rock climbing (although there is a lot of skill involved, you don’t have to understand the gears to succeed, you can learn to intuitively make efficient motions that move you up without understanding too much about why or how that happens)
meditating (although lots of people get into the gears, plenty of people successfully meditate either without a deep understanding of what they’re doing or possibly actively mistaken theories that work anyway)
Again, I’m sure there are more, and I think for all of these there’s plenty of room to argue on the margins.
If I had to guess at what the divider is it’s something like how robust the ontological abstractions around the topic are at levels that matters for the task. The more robust, the less like baking, the more fragile and leaky, the more like baking.
To say a little more, programming is the thing that resonates for me most strongly with the above description of baking as not ritual. I notice it because there are lots of people who learn to program by ritual. They do well enough to get jobs and become my coworkers, but then they also write code full of cruft because they are programming by ritual rather than through deep understanding.
The classic examples of this that come to my mind are things like people thinking the iterator variable on a
forloop must be namedior else it won’t work, or struggling withsedbecause they don’t realize they can pick the separator character on each invocation, or thinking they need [technology X] because they heard successful businesses use [technology X].To add to this, I’ve noticed something that I do when I’m programming is rely on various constructs/built-ins that I have a solid gears-level model of. I often find myself unwilling to use functions/constructions where I don’t understand why they do what they do because I’m worried that the code might cause unintended effects that cause bugs, especially since debugging is extremely difficult without gears-level models.
I think the ideal programmer maintains probability distributions over whether or not they understand what various parts of their code is doing. If there is a bug, then they have some weighting over where the bug probably is, enabling faster debugging.
I’m in the midst of a career transition into computational biology. I taught myself coding at a young age and find it intuitive, but I’ve never worked in a tech job before. This reassured me that if people who don’t know that an iterator variable doesn’t need to be named “i” to work, that I can get a job in tech too, since I’m at least beyond that. Thanks :)
On the other hand, not knowing this might be like the 2-4-6 problem, where people just never thought to test this assumption. It would be entirely possible for a programming language to limit you to “i” (although nested loops would get weird). I wouldn’t call this a lack of conceptual knowledge, as much as one thing they haven’t tried. Having bad naming like this is bad [style](http://paulgraham.com/taste.html) , in my opinion, but doesn’t mean that whoever doing it must be a bad programmer.