Memorization equals learning.
For many of us, it’s how our understanding was assessed. We were praised for memorizing the alphabet, numbers, the four nucleotides in DNA, and x is equal to negative b plus or minus the square root of b squared minus 4ac all over 2a. I imagine that somewhere out there my former math teacher is smiling.
Many of us have held on to that belief. I did when I was learning my programming basics. I spent so many hours attempting to memorize the syntax of a for loop. So many evenings where I’d try to recite the names, syntax, and return values of array methods. And many nights where I read and re-read the documentation on React, wishing I could just tattoo it to my brain.
I’ve spent the past few years helping people learn to code at The Odin Project and I’ve noticed a lot of people there are doing the same. At least a few times a week folks come in to our Discord server to ask about the best note-taking techniques or to express concern about moving to a new topic for fear of forgetting what they just committed to memory.
Here’s a hard truth: the concept that you spent hours trying to memorize that you feel has finally stuck- you’re going to forget it. Don’t freak out though. That’s ok. That’s normal.
The greatest concern I had once starting my job as a software engineer was whether I had enough in my brain. I was afraid of pairing with more experienced engineers at work because I didn’t want them to discover how little I knew. When we did pair I was embarrassed that I couldn’t recall a syntax for a some method or recall the return value of another. There was a pairing session I had with my colleague, John, where this all changed.
While pairing on a task, the idea of localStorage came up. I mentioned that I used it a few times in the past, hoping to impress my new co-worker. John invited me to tell him about it. There isn’t a way to dress this up: I FREAKED OUT. I couldn’t think of a thing to say. I apologized and said I forgot everything about it. But I gave myself a few seconds to think and finally told him there was a way to set and retrieve information but I had nothing beyond that. I was afraid of his response. I was expecting he’d say it’s crazy I hadn’t memorized everything about localStorage and go tell my boss that hiring me was a mistake. Instead, John shared something like this. His exact words are hazy but the spirit of it was:
“That’s ok. I haven’t used that in years myself. Let’s google it together and figure this out.”
The conversation continued and I remember little about the technical stuff. The fact that he didn’t flip out was shocking and that stuck with me. At the end of the pairing session, we discussed the need of revisiting documentation. John shared that he googles and reads documentation regularly. And shared that it is very normal to not have everything memorized. I always imagined that great engineers knew everything. I imagined they carried all their knowledge all the time and could recite any of what they held in their brain whenever they wanted. After all, I was under the impression that memorization equaled learning, which in turn led me to believe that I was only as good and skilled and useful as my memory. John taught me that this is far from the truth.
Now that I’ve been in the field for a few years, I find that I very much agree with the sentiment that John shared. I regularly forget how to use stuff. I forget syntax, return values, even names of methods. If I haven’t used Flexbox in a while, I’ll need remind myself on how to center a div. But rather than freak out, like I used to, I know that I can visit documentation to refresh myself on things when I need it.
When we are actively engaged with a topic, that topic is easy to carry in our working memory. And the hope is that our efforts in studying a thing will move that thing into our long-term memory. For many, falling short of putting everything we engage with into our long-term is failure. Moving things from our working memory to our long-term memory is hard. And to make matters worse, working memory is not unlimited. This means that as we become familiar with one thing, another thing will fall out of that working memory. This causes concern to a lot of people. We end up returning to things we feel we’ve forgotten every time we learn something new. Except in revisiting that thing we forgot, we now risk forgetting that thing we just learned. Then we’re in a cycle where we’re constantly trying to hold on to everything at once. And if we’re constantly trying to hold on to what we know, what room do we have for learning new things in peace?
In the real world, no one holds on to everything all the time. We’re more likely to hold on to the general idea of a thing and less likely to hold on to the details. And in the adventure of learning to code, there is little difference in the utility between perfect memorization and being vaguely aware.
Knowing that it’s possible to remove the last element of an array is just as good as having the syntax of JavaScript’s pop method memorized.
❗ FULL DISCLOSURE ❗: As I typed the sentence above, I was like: “is the pop method even the one that removes the last element of an array?" Me 2 years ago would have freaked out and felt real sorry for myself. Not this time. I cracked open a browser tab and looked at the documentation and confirmed that was the case. Cool!
As we engage with ideas over time, we’re more likely to move larger concepts into our long term memory than the finer details associated with those concepts. As with the example above, we’re more likely to remember that there is some way in JavaScript to remove last element of an array instead of perfectly memorizing everything about the pop method.
We can’t memorize everything. But we can become aware of a ton. Equipping ourselves with awareness of what to research is good enough for getting through learning. Over time, and with lots of practice and mistakes and experimentation, things will stick.
Being vaguely aware is enough.
Disclaimer:
Having some stuff memorized by the time you get to interviews is useful. But by the time you get there you'll be surprised by how much has stuck. The thoughts I’ve shared here are specifically for folks actively in the learning process.
Top comments (44)
Excellent text. I've been learning on The Odin Project for a year now, but even today, I sometimes forget that the goal isn't to memorize everything, but to know that something exists/is possible, and then I Google it and find the syntax on MDN Web Docs to solve the problem. It's the same for everyone on any platform, no matter how good it is – we all face the same challenges.
Extremely encouraging and well said. I’m sure there are many like me who hear the familiar knock on the doors of our minds by that dark shadow called Imposter Syndrome whenever we forget something. This is a helpful reminder, perhaps an epiphany for some.
Thank you SO MUCH for this post. I really needed it. Having just started out trying to learn coding - especially JS, React etc. - after being diagnosed with ADD, which in itself impairs the ability to "return" things from memory so even though you know it, you just can't recall it - this write up really gave me some hope that I will be able to make it through my learning. So thank you.
I realized how important that external memory is to me when I tried to write Python code without Google. It hurt.
On the other hand I learned something wonderful some of the heroic programmers of old had: they had texinfo documentation. Full-text search in the actual docs of the programming language and libraries you're using, all well-structured, so you can search for functions, check out the API listing, and so forth.
Try programming in GNU Guile for once and run
info guile referencein a shell. The coders of old could do without Google and Stackoverflow (though SO is undoubtedly awesome and the prime method to quickly get an answer) because they had manuals that were actually useful.That’s like mdn, but local. And faster — those tiny delays on every action actually matter during quick access to your external memory.
Though the manuals often were on paper, heavily diminishing their value (do you remember how Emacs calls itself self-documenting? That used to be a power-feature). And lacking in their own ways … (the Guile reference lacks in examples).
Now if Google fails us, all we can hope for is usually good API documentation that if we’re lucky gives us enough hints in the IDE that we can discover what we need during coding.
Or hope that we have tldr installed … (which is a tool that likely would have had the coders of old drooling in awe, even though the one I have here is too slow for comfort; need to find another implementation).
A good engineer does not know the answer to every question or the solution to every problem, but he knows where to find it.
Really? I'd be shocked if someone did flip out about that 😀. Seriously, though, I always hope that people do what they can to ensure that kind of behavior is not normalized. Some engineers feel that their passion gives them permission to berate their colleagues (I've seen it first-hand). It's important to teach those people that they if they want their professional opinion to be respected, they need to express that opinion professionally.
Spot on. I think the important thing is to acquire a general impression of the shape of things and the capabilities of the tools you use. I use templates and searchable notes to supply the details. When these fail, I Google for assistance - w3schools and mozilla are my standard "gotos".
Another thought is that I strongly believe that if you focus too much on memorising detail you lose sight of the "big picture". Boy, do I struggle with this right now. Was there ever a time when IT development technologies offered so many different options?
Thanks for sharing Carlos.
I agreed with this statement:
"We can’t memorize everything. But we can become aware of a ton. Equipping ourselves with awareness of what to research is good enough for getting through learning"
Essentially have a cursory breadth and awareness is useful to know the thing exist and then research deeper when you needed it. With AI generative tooling like ChatGPT that's gold.
On the other hand, I'm not a fan of memorization for interviews.
It's liken to a puffer fish blowing up spiky body to look competent.
"Having some stuff memorized by the time you get to interviews is useful. But by the time you get there you'll be surprised by how much has stuck."
In fact, I'll argue that most people suffered from LRU(Least Recently Used) memorization failures at interviewing rounds.
You get lucky if the most recently memorized algorithms and coding problems are being asked. Otherwise, it probably the case that you can't recall and looking bad on the spot.
this is perfect, well said unfortunately though we may not all be fortunate to meet people like john in our life but as a young aspiring developer one of my greatest fears and i guess what keeps one in tutorial hell is the fear of never knowing enough but if the big Engineers sometimes have to google themselves that sort of gives me a sense of relief and i hope one day i too can look back and smile at all this, thank you for the amazing article.
Well said. I am older than most. Memory is a very short lived thing for some stuff. If I work with a particular language intensely and over a period of weeks, much of the basic stuff is easy to do. But, if I stop and switch to another, my facility with the other language decreases over time.
This is especially true with me because I am drawn to the languages with C-like structure. Yet, I find that some do a "for" loop differently. A few don't do it at all. I'm often scratching my head and heading to Google for the answer. Not a prob. Now, back when we only had books...