[chmod775]

> Consider if you are in the middle of a calculus exam and need to evaluate $7 \times 8$ by calculating $7+7+7+7...$ and then proceed to count on your fingers up to 56 because even $7+7$ wasn't memorized. You're almost certainly not going to make it past the first problem on your exam even though you really do understand exactly whats going on.

This is not a counterexample because exams aren't an end goal. The process of filling out exams isn't an activity that provides value to society.

If an exam poorly grades a student who would do great solving actual real-world problems, the exam is wrong. No ifs. No buts. The exam is wrong because it's failing the ultimate goal: school is supposed to increase people's value to society and help figure out where their unique abilities may be of most use.

> Similar things are true for software engineering. If you have to stackoverflow every single line of code that you are attempting to write all the way down to each individual print statement and array access it doesn't fucking matter HOW well you understand whats going on/how clear your mental models are. You are simply not going to be a productive/useful person on a team.

If their mental models are truly so amazing, they'd make a great (systems) architect without having to personally code much.

[sim04ful]

I can't totally agree with your counter-counter example. Most non trivial problems are time bound, deadline exist, and no matter how well ingrained you are in first principles thinking you won't be useful if it takes months to come up with a solution.

[skhunted]

To know something includes speed of regurgitation. Consider a trauma surgeon. You want them to know, off the top of their head, lots of stuff. You don’t want them taking their time and looking things up. You don’t want them redefining everything from first principles each time they perform surgery.

Knowing a topic includes instant recall of a key body of knowledge.

[1659447091]

I would say knowing and understanding is not necessarily the same. In this example the surgeon having both understanding and memory/knowing is best/required. If I had to pick between the two, I want the one that understands my particular trauma, even if that means they have give instructions for someone else or a machine to performing it.

I think an example closer to the above posts would be: If I needed cpr or defibrillation, I would much prefer a paramedic be next to me and make that call and performance than a med student or a defibrillator manufacture's electrical engineer.

[westurner]

Maybe survey engineers with a first order derivative question and a PDE question n years after graduation with credential?

CAS and automated tests wins again.

A robosurgeon tech that knows to stop and read the docs and write test assertions may have more total impact.

[skhunted]

I’m ABD in math. It was 30 years ago that I decided to not get a Ph.D. because I realized that I was never going to be decent at research. In the last 30 years I have forgotten a great of mathematics. It is no longer true that I know Galois Theory. I used to know it and I know the basic idea behind and I believe I can fairly easily relearn it. But right now I don’t know it.

[westurner]

That's wild, we all use AES cipers w/ TLS/HTTPS everyday - and Galois fields are essential to AES - but few people understand how HTTPS works.

The field is probably onto post-AES, PQ algos where Galois Theory is less relevant; but back then, it seemed like everyone needed to learn Galois Theory, which is or isn't prerequisite to future study.

The problem-solving skills are what's still useful.

Perhaps problem-solving skills cannot be developed without such rote exercises; and perhaps the content of such rote exercises is not relevant to predicting career success.

[frogeyedpeas]

> 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.

[1659447091]

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.

[pfortuny]

You can only think using memory.