Your comment reminds me of paper by Bestsy Sparrow [1] where she hypothesizes that "Our brains rely on the Internet for memory in much the same way they rely on the memory of a friend, family member or co-worker. We remember less through knowing information itself than by knowing where the information can be found." [2]

From the papers Abstract:

"No longer do we have to make costly efforts to find the things we want. We can “Google” the old classmate, find articles online, or look up the actor who was on the tip of our tongue. The results of four studies suggest that when faced with difficult questions, people are primed to think about computers and that when people expect to have future access to information, they have lower rates of recall of the information itself and enhanced recall instead for where to access it."

[1] Google Effects on Memory: Cognitive Consequences of Having Information at Our Fingertips - https://www.science.org/doi/abs/10.1126/science.1207745

[2] https://news.columbia.edu/news/study-finds-memory-works-diff...

I immediately thought of the book "Thinking, fast and slow" from reading your comment. I don't know if you're familiar with it, but it talks about two "Systems" that guide our thinking. From the description of the book: "System 1 is fast, intuitive, and emotional; System 2 is slower, more deliberative, and more logical."

The more you do something, or think about something - the more it becomes a "System 1" operation(fast, intuitive). Like typing on a keyboard for example, when you first started using a keyboard you had to think about every letter you want to hit, but now you probably don't even think about it for a millisecond. I guess what I'm trying to say is: Intuitive understanding = Action * Repetition.

Read the book if you haven't, it might be the kind of material you're looking for. I'm not a big fan of psychology and I think it's 90% mumbo jumbo, but this book hit a few nails for me.

Thanks for the suggestion! I've actually read TFS, and I would even consider myself a "fan" of psychology, I definitely don't think it's mumbo jumbo. But in my opinion the book was quite shallow, only scratching on the surface of the matter.

Edit: To clarify, shallow is maybe the wrong word. I think the book gets its main point across very well, and it's a good point. But the majority of the book is just further evidence supporting that main point. Which is fine, but I wish it would develop this main point a bit further. The book could be summarized in a short paper and wouldn't lose too much of its value, in my opinion.

Note that there is quite a bit of shaky evidence used to further that point.

https://replicationindex.com/2020/12/30/a-meta-scientific-pe...

> I sometimes have to google for the names of functions I've already used a hundred times

This is why I have always been terrified of having to do a standard 'whiteboard' coding interview, and really don't want to ever participate in administering them to others. I know if I was ever tested in this way, I would be unable to remember the basic function names in languages I have used daily for years... and yet I have developed sophisticated software tools in these languages with a large global userbase. I fear that in an interview people would decide I am a fraud, and couldn't have really done what I have done when it appears I actually don't even remember the basics. But my mind just doesn't work that way, I can't remember length vs size either, even if I can design a complex algorithm, and turn it into a good piece of software under the actual conditions of work in the real world.

I've written plenty of whiteboarding interviews in something resembling Java and decided that I needed a tuple class, which for most purposes doesn't really exist in Java. So I just used the concept of a Tuple. I can say that most people on a whiteboarding interview panel don't really care if you borrow abstractions of ideas, the most I've been asked to do is define an interface for these implementations.

Honestly if they care that much about rote memorization of syntax, it's a red flag.

Good whiteboard interviewers will happily stipulate that something like the thing you can't remember the name of definitely exists and you can call it whatever you want in your solution.

> This is why I have always been terrified of having to do a standard 'whiteboard' coding interview

I too don't like the idea of these, but in the case where you're solving a problem in front of someone I feel like as long as you explain your thought process you'd be generally fine. If you can't remember whether the method is length() or size() or something else just pick one and explain what you're doing. Intelligent interviewers would likely understand that you're familiar with the concepts and would be able to accept your result or let you compile/execute and fix the issue.

back when whiteboards were a thing, most were not testing exact syntax..

I think it feels different because that knowledge is more deeply ingrained with what you already know. That knowledge has many connections and relationships with other knowledge you have. Whereas the name of a function is more like a leaf node, it isn't connected to very much and i think this is the source of the different feelings you describe.

To expand on this a bit - our memories maintain "schemas" of knowledge and whenever we learn something new it gets slotted into our "schema". The better something fits into our schema the easier it is to remember. I think if you googled schemas you'll be able to find more material on this

I'm not sure I agree. I think what I tried to describe above couldn't be classified as "knowledge" at all.

To be honest, I think we (humans) don't understand this type of understanding very well. Which is somewhat ironic :-)

Edit: But thanks for the suggestion about searching for schema, will definitely take a look!

The keyword embodied may be fruitful — there is a lot of noise around the term but embodied understanding is closer to what you want, I think. You may have to relax some ideas about how things work for a while in order to absorb/integrate it.

The knowledge defined in the article is very rational and reductionist in its presentation. I don’t mean that derogatorily, but it does mean it can’t account for all the emergent features of our existence. The reductionist approach can be useful as a set of signposts for locating reliable mechanistic constraints.

Thank you for that keyword! A quick search brought me to the wikipedia article [1], which sounds quite promising.

I agree completely with your analysis of the article by the way. Beautifully said!

[1] https://en.wikipedia.org/wiki/Embodied_cognition

Understanding is just knowledge of how or why something works

Intuitively, I don't believe it's that simple. But I'd love to learn more about it.

There may be more to it but at a minimum understanding usually requires you to remember a how or why, so understanding is rooted in memory as well. Perhaps also the memory of a broader cognitive context of the world and how a given objects fit in that context. Without memory there would be no capacity for understanding.

Have you ever gained a solid understanding of a complex topic after a lot of study? When you start to forget the relevant details of the context you’ve created, your understanding fades as well. “Understanding“ is just a complex function of memory to a large degree.

I think you've touched on two different ideas:

(1) That a deeper understanding of something can make it simpler/easier to remember. One way to look at this is that you remember a model of the world. That complexity of that model determines the quantity of information you need to remember. If you can find a simpler model, your mind needs to store less information to cover everything you need to know.

(2) That a concept and its name are different things. You understand the concept of an array-length-giving function, but you don't remember the name attached to it. It could go the other way: you could know there is a function with a certain name but not remember what it does. Or you could know what it does and what it's named. (This seems at least tangentially related to linguistic relativity (https://en.wikipedia.org/wiki/Linguistic_relativity), a.k.a. the Sapir-Whorf hypothesis. The question is basically to what degree our minds build ideas on words/language and to what degree we form ideas independently of language.)

Reminds me of Feynman's anecdote about the names of a bird.

> See that bird? It’s a brown-throated thrush, but in Germany it’s called a halzenfugel, and in Chinese they call it a chung ling and even if you know all those names for it, you still know nothing about the bird. You only know something about people; what they call the bird. Now that thrush sings, and teaches its young to fly, and flies so many miles away during the summer across the country, and nobody knows how it finds its way.

The name is first and foremost a way to attach that deeper knowledge of the bird to a symbol so it can be communicated to others. The name is necessary, but usually tells you very little about the thing it refers to.

Counter-anecdote time from Murray Gel-Mann, who did think names were important [1]

[1] https://writings.stephenwolfram.com/2019/05/remembering-murr...

I don't think anyone in computers can purport to names being important. Shell's sort, Bloom's filter, awk, c++, Java vs JavaScript....

The number of names that are misleading or almost willfully obtuse is absurdly high. (I'm actually cheating for folks in my list, as I typically see it just shown as shell sort and bloom filter. Which hides that it is named for someone.)

At least Shell invented the sort named after him. In the sciences you have Stigler's Law (no scientific discovery is named after its original discoverer). https://en.wikipedia.org/wiki/Stigler%27s_law_of_eponymy

That is hilarious! Yeah, my qualm is less about Shell's sort being named after him, and more that many places present it as shell sort, where you can easily think there will be some form of shell game involved. Akin to thinking a bloom filter must be something about growth or flowers blooming.

I also don't mind algorithms named after people, and can understand some of how that gives provenance, at the least. The Knuth-Morris-Pratt algorithm is a good example of that. What makes things difficult is that many of the other sort algorithms were not after people's names. Unless there is a Merge that I am unaware of. :D

It's interesting you mention playing the piano as an example, because that's a very good example of how the opposite of what you're saying is true. Try to learn a piano piece simply by playing it many times, and it'll never happen. However, try to commit the notes intentionally to memory, and reading the notes becomes unnecessary very quickly. Same with trying to memorize text; if you read without explicitly trying to memorize it, you can read it infinite times and never manage to recite it back.

I think your example about list.size doesn't contradict this. It's the difference between "familiarity recognition" memory vs "consolidation and retrieval".

You do not bother committing "size()" because it's unnecessary (or because there's a lot of interference from other languages which do the same thing, hence the cost of committing that fact for later retrieval is not worth doing so).

But you have committed the "concept" to memory, and this can be retrieved even without the need for the label.

"Understanding" is only part of the equation. But I do generally feel that "having the basic building blocks readily available helps you build complex understanding on top of them, which then helps you consolidate the complex stuff better" is probably the main direction, rather than "understanding a complex concept helps you better remember the basic building blocks that made it up in the first place".

This is also why anki works so well for learning theoretical subjects (even if it has traditionally been more popular for pure memorization tasks, like language learning)

You still have to remember your understanding. That's something you realize when it has been a long time since you took a class on something back in college.

True that there's a large difference between information and knowledge but I think the intrinsic part of knowledge itself is the ability to recall information i.e. remembering.

I started using Anki (A spaced-repetition tool) to improve my long term memory by creating cards for everything I like to remember no matter how trivial it might be, Then the act of reviewing the Anki cards became a chore.

I'm currently trying to solve the problem of reviewing Anki cards by having an always-on review system[1] which lets me review cards when ever I want instead of a rigorous schedule.

[1] https://memoryhammer.com

My guess: the concept of "a length of an array" is the thing you use to think with when you need it.

Why?

Because it is a single entity(through abstraction). And because it is a single entity and you use it a lot, it gets connected to many other concepts.

And because you've solved problems with it,it has more emotional value.

This means you can more easily retrieve it and it has more "meaning"/context to you.

list.length gets used less often and it just a concrete implementation of the concept so maybe it's just linked to the concept.

And it's also more complex to remember and use because it's made of 10 items.

> google for the names of functions

Copilot is a lifesaver here. I almost never have to google function names anymore because it just fills them in for me, while usually generating exactly the code I wanted around it.

I've resisted co pilot and auto complete because when interview time comes and you have to write code outside of your toolset, you'll realize you haven't committed things so well to memory. This bit me earlier on in my career after working in visual studios for a long time. I now code almost exclusively in vim.

I'm not saying you shouldn't use it, but before you go into technical parts of interviews I would recommend you do some coding without all the bells and whistles tools.

Why would you give up such big productivity multipliers just to make the rare event of interviewing a little easier? If an interview is coming up then just spend a few days practicing, or just don't - I've never had an interview go badly because I didn't memorize java.util.date.

Not saying that your advice in any way wrong, but it's a bit sad that the only thing holding people back from such a productivity multiplier, innovation or even completely new way of coding is the inane interview process of this industry...

The paradox of copilot is that anyone who is skilled enough that they can be responsibly trusted to use it doesn't need it.

Completely agree.

If only there was a way to know which methods the object has. We could call such concept something like auto-discovery or magic-completion.

I use that too, but Copilot is just better much of the time.

Great. If i ever feel like my impostor syndrome could use a bump I'll be sure to throw Copilot into the mix.

Curiosity got to me and I finally tried the GitHub Copilot free trial. My conclusion is that it's good for that stuff I would have googled, like "I can't remember, how do I get the date again?" or "Is it array.count() or count(array)?" Instead of typing it in Google I just type it in a comment. It's like having google in the IDE.

It's even harder to remember specific standard library functions after learning several programming languages. I know the languages themselves but still have to look this stuff up every time. One reason why Ruby is such an ergonomic language is there are aliases for all those names: you can guess length, size and count and chances are all three will work.

I have the same feeling, "knowledge" is more about knowing what is available, what options are there and broadly what each option does. You don't have to remember exactly how each option works, just know that it exists. When you need it, you can just search how it works, but knowing what to search for is crucial.

On the other hand, to the point of the article, you can't get a deep understanding of a concept without remembering the concept, other concepts that it relates to, and how.

> There is a difference between remembering something (like a fact) and a deep understanding of a concept.

This is basically the Searl argument against AI, right?

Yes! This is the case for me. I have a hard time remembering exact things, but have very goed understanding of their concepts.