> Re: "this is not a counter example because exams aren't an end goal..." for any end goal with a set end time there are habits that need to be second nature and information that one needs to know in order to achieve that goal. If you lack those habits and don't know those facts it's going to be very hard to achieve that goal.
I used the example of a calculus test and not being able to do addition. But this really could be any example. It could have even been a Wide Receiver failing to read the play thats happening quickly enough despite being physically fit enough to execute the right play in hindsight.
>Re: they'd make a great (systems) architect...
But you wouldn't hire them as a programmer. My sentence was biased in the sense that "team" meant "team of software engineers". You would hire them for a different job sure.
Also good mental model here just means "Always knowing and being able to clearly articulate what I need to accomplish next to write my code". It doesn't even mean they are good at designing systems but lets go with that example anyways below:
The Architect version of this is that they perhaps have perfectly clear mental models of exactly how to code (memorizing very obscure language shortcuts and syntactic sugar and writing very clear code when they know what to build) but they cannot for the love of god think critically about what a design should be BEFORE they implement it far enough to reach a major issue.
And you would rightly say "well I would never hire that guy as an architect but I might have hired them as a programmer thats led by more senior folks". At the end of the day you are only hiring people for the parts of their mental models that are useful.
And the ability to clearly recall facts about that their domain is basically the fundamental detail here.
I agree with you that memorization is an optimization for getting daily task done (maybe not as optimal when novel solutions are needed; understanding/mental model might win out here). But we have tools to help take the load off memorization. The person that `understands` addition not as 7 + 7 but as incrementing a number a certain amount of times can use a calculator to solve the problem in a more efficient way.
I would probably not make a developer who had great mental models but lacked coding chops my first hire. Nor the programmer that could make code do amazing things but can not grasp the domain model. I would, however, probably consider them(the mental model one) the 100th to clean up backlogged bug fixes, and the code whiz to implement the more technically difficult backend niche feature/optimization. As much as it pains me to say it, github copilot chat works surprisingly well IF you can give it a clear concise description of the model and expectations. Then someone with an excellent mental model can create the smaller lego pieces and put it together, minimal coding required. Not only for the popular languages, I play with it from time to time using clojure.
I used the example of a calculus test and not being able to do addition. But this really could be any example. It could have even been a Wide Receiver failing to read the play thats happening quickly enough despite being physically fit enough to execute the right play in hindsight.
>Re: they'd make a great (systems) architect...
But you wouldn't hire them as a programmer. My sentence was biased in the sense that "team" meant "team of software engineers". You would hire them for a different job sure.
Also good mental model here just means "Always knowing and being able to clearly articulate what I need to accomplish next to write my code". It doesn't even mean they are good at designing systems but lets go with that example anyways below:
The Architect version of this is that they perhaps have perfectly clear mental models of exactly how to code (memorizing very obscure language shortcuts and syntactic sugar and writing very clear code when they know what to build) but they cannot for the love of god think critically about what a design should be BEFORE they implement it far enough to reach a major issue.
And you would rightly say "well I would never hire that guy as an architect but I might have hired them as a programmer thats led by more senior folks". At the end of the day you are only hiring people for the parts of their mental models that are useful.
And the ability to clearly recall facts about that their domain is basically the fundamental detail here.