DEV Community

Carlos Diaz for The Odin Project

Posted on

Memorization and learning to code

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 (37)

Collapse
 
zupi profile image
Zupi-HR • Edited

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.

Collapse
 
tjohnson009 profile image
Tim Johnson

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.

Collapse
 
madsklitgaard profile image
Mads Klitgaard

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.

Collapse
 
arnebab profile image
Arne Babenhauserheide

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 reference in 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).

Collapse
 
tardisgallifrey profile image
Dave

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

Collapse
 
mjoycemilburn profile image
MartinJ

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?

Collapse
 
ben profile image
Ben Halpern

Great post

Collapse
 
bklau2006 profile image
BK Lau

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.

Collapse
 
princemuel profile image
Prince Muel

💯 me. Anytime I learn something new, or encounter something useful, I ask myself... "in what situation would I need this?". Once, I have my answer, I'm free to make a mental note for the use case then forget about it until run into a situation where I need it. This has never failed me...yet 😁

Collapse
 
squidbe profile image
squidbe

I couldn’t think of a thing to say. I apologized and said I forgot everything about [localStorage].... The fact that he didn’t flip out was shocking and that stuck with me.

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.

Collapse
 
lukaskrimphove profile image
Lukas Krimphove

A good engineer does not know the answer to every question or the solution to every problem, but he knows where to find it.

Collapse
 
olivia73code profile image
Olivia73-code

This was great to read, thank you. I am at the very beginning stages of learning (HTML) and I have often wondered how I will remember everything. However, I am good at making notes and have been able to understand the documentation I have read when a point needs further clarification. Thank you for sharing!

Collapse
 
debbie1505 profile image
debbie1505

This is so good and is really going to help me learn better going forward. I've always have shame with forgetting syntax, and I've always thought I should remember syntax for me to consider myself a programmer. But this article took that shame away and validate that it is okay to forget syntax and it is okay to google stuff. And a statement that stood out to me is "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.". And now I'm going to focus on being aware of ways to solve a problem instead of remembering each syntax, I could just google it.

Collapse
 
sergionr profile image
Sergio N

Good lord! Created the dev.to just to share my sincerest gratefulness

In my head i kept wondering if i was failing since i keep not-remembering some methods and having to look back at documentation

thank you!

Collapse
 
adriand profile image
Adrian Dobre

One of the best MOOCs I followed was Barbara Oakley's Learning how to Learn. In a Talk at Google, she summarized her research and mentioned memorization as a positive thing. Here's the video at 45:15 when she explains it https://youtu.be/vd2dtkMINIw?feature=shared&t=2714

I'm trying to figure out now the best way to supplement my Odin Project learning with tests that are at the same skill level.