loading...

To memorize or not to memorize?

scottshipp profile image scottshipp ・3 min read

What should I have memorized?

Every week I see a post somewhere like Latency Numbers Every Programmer Should Know, TOP 10 ALGORITHMS EVERY SOFTWARE ENGINEER SHOULD KNOW BY HEART or 6 Git commands every beginner should memorize.

After a certain point in time, I began to realize that if I actually memorized all of this stuff—or tried to—I might be spending all my time memorizing and doing little else.

It really begs the question, what is worth memorizing?

I thought it might be an interesting thought experiment to entertain the options.

Option 1: Everything

Clearly, trying to memorize everything is an option. But I can see that it's ridiculous on its face. What even is "everything?" Defining that would take the rest of my life. Even if I somehow could get past the part where I define "everything," I'd still spend all my time memorizing and never building.

So I discard this option.

Option 2: Almost everything

Having discarded option #1, do I take the approach of starting with "everything" and just throwing out things I don't want to memorize? Throw out physics and chemistry perhaps? Just computer science? Or can I throw out all the stuff about punch cards and ENIAC and floppy drives that store only kilobytes of data. Do I throw out sort algorithms and Parnas tables and COCOMO and bit-shifting? I don't know. Where do I draw the line? I could probably spend most or all of my time just figuring out what not to memorize. I really need to pick a boundary right off the bat, rather than trying to cut things until I actually have something I can get my hands around.

So I discard option #2.

Option 3: Everything in a focus area

What if I throw out hardware-related knowledge? Or things outside my particular focus like mobile apps or embedded software since I'm a web services engineer?

That might be an idea. Let me memorize everything related to web services.

Hmmm...that still doesn't seem right. Early web applications and services were written in CGI and Perl. Then the era of the LAMP stack ruled for awhile. Now its such a fragmented world that I couldn't think of getting it all memorized. People are doing interesting things with Ruby on Rails, Flask, Node, AWS Lambdas, and Spring. Each thing is its own universe.

That still seems like too much.

Option 4: Everything in an ecosystem

Option #3 gave me an idea. What if I just focus on something really defined, like Spring?

OK but there's all these projects within Spring that I will probably never touch. The term "Spring" encompasses, for example, Spring Data, Spring MVC, Spring Boot, Spring Batch, Spring Security, etc.. And all of these things have their own web sites, plus a galaxy of supporting sites with tutorials, videos, books, conferences, and more.

That doesn't seem productive either.

Option #5: Almost Nothing

“Never memorize something that you can look up.” — Albert Einstein

If Einstein said it, is it right? He was certainly one of the smartest people who ever lived. And considering that it's even more easy in 2019 (almost 2020 now!) to look things up. The phone in my pocket has nearly every answer.

At the same time, I do in actual fact have a lot of things memorized just because I do them every day. I know how to clone a repo from Git, open it in IntelliJ, write tests, implement classes and methods, make and squash commits, and finally push it up and open a merge request. All without googling or looking anything up. So clearly I have done some memorization. Just maybe not the classic way with flashcards and textbooks.

So what's the answer?

Honestly, I have no idea. But it does seem clear that memorizing lists of things from blog posts isn't an approach that I'll personally be taking.

If you know, maybe you can tell me?

Discussion

pic
Editor guide
Collapse
ahferroin7 profile image
Austin S. Hemmelgarn

Ideally, you need to get to the point that you remember the concepts, not the specific implementations or exact design choices. Concepts are transferable, implementation is not.

So, for example, if you're learning how to improve the efficiency of a search, it makes more sense to understand how and why a binary search is efficient than exactly how to implement one in any given language, because understanding the algorithm means that you have an easier time implementing it no matter what language/platform you are using.

The Einstein quote is a good one, but it's better phrased (far more verbosely) as "Don't spend time memorizing things you can look up because you'll naturally start remembering the things you actually need to know as you use them.". IOW, there's no point in spending all your time trying to remember how to do things, because you will end up remembering what you actually need to use frequently and can look up everything else.

Putting all this together with what you put in your question, you already know how to clone a git repo because you do that regularly. That, however, is a combination of a concept and the actual implementation. The concept works the same in almost every widely used VCS implementation, and is highly transferable. So, if you suddenly had to clone a mercurial repository instead, you'd probably not need to do much more than look at the output of hg clone --help to figure out how to do it.

Collapse
narhkpodo profile image
Daniel Narh

This is an incredible reply that needs over a 1000 love likes

Collapse
themobiledev profile image
Chris McKay

Definitely this. In our day-to-day at work, it's expected that we'll be looking things up. We joke about copying and pasting from Stack Overflow all the time because we know it's true. It's even encouraged during our technical interviews. What we value is being able to learn, understand and retain concepts. Even now, we're currently throwing away our old tech stack, so it's more important than ever to understand the "why" than the "how."

Collapse
joshuatz profile image
Joshua Tzucker

One approach that I like is to combine "memorizing almost nothing", with writing things down for myself. Basically, my rule of thumb is that if I have to look something up more than twice, I write down the answer in a Markdown cheatsheet. This has three major benefits:

A) The next time I need to look it up, I can just CTRL+F in my cheatsheet repo and easily find exactly what I am looking for. It is also usually much easier to grok my own notes than what others have written - my brain likes my own writing style :)

B) Writing things down helps cement them in your brain, without even consciously trying to remember them. I always find that I have improved recall of something after I write it down.

and finally,

C) Since I don't normally allow myself to copy and paste into my cheatsheet, writing something down usually means I need to reword it, which forces me to learn the topic enough so that I can talk/write about it.


Plus, a collection of cheatsheets can become a fun programming project. I integrated mine with GatsbyJS to auto-publish them to the web (they are here if anyone is curious).

Collapse
kleene1 profile image
kleene1

Nice one

Collapse
hackulis profile image
Edu Rich

You have a really great cheatsheet right there!

Collapse
joshuatz profile image
Joshua Tzucker

Thanks! I'm constantly adding to it as I learn!

Collapse
peledzohar profile image
Zohar Peled

I never attempt to memorize anything anymore. What I work with on a regular basis creeps up into my memory even if I don't want to, and what I don't remember I go seek out help from the developer's best friend - the internet.

IMHO - More than anything, what you need to do is sharpen your searching skills - This means that you need to know what to look for and where to look for it, and at least equally important - what to trust in the search results - but you really, really don't need to memorize anything.

I'm glad to see that Albert Einstein held the same position on this subject.

Collapse
frankfont profile image
Frank Font

Read "Moonwalking with Einstein" then memorize anything you want to memorize. And it is okay to fail. Because it kind of does not matter.

I like memorizing jira ticket numbers while they matter and then forget them once they don't.

Seems like a silly thing to memorize but it's not.

My criteria for what matters enough to memorize is that it is something that empowers YOU TODAY so YOU do more of what you want with less distracting interruption.

Go for it. And then happily forget these things because you can always look them up anyways.

There is no must.

Collapse
ugglr profile image
Carl-W

Good post!
The docs change daily! Why clutter your brain with that, right? Just look it up when you need it.

I like to keep the mind clear, however, haha it makes me sound completely incompetent when talking with other engineers because I'll always answer with generalities. Stereotypically there's this underlying competition between SW engineers where we try to sound smart all the time, and try to one up each other that our current stack is "correct" or "hey look at this Medium article, but he forgot about this and this, what a tard". I can never join that conversation because I don't keep the detailed workings in my memory.

If we are talking about concepts I try to understand them on a high level, and gradually I don't need to look things up as I use them daily.

Collapse
elmuerte profile image
Michiel Hendriks

You should not memorize anything. It does not work and completely wastes your time. Things which are important to you, you will remember automatically. Things you use often you will remember automatically.

For everything else, just store pointers or references which will help you to look it up when it is relevant. Like Albert said.

Collapse
shiftyp profile image
Ryan Lynch (he/him)

This is an interesting question! As a learner I experiment, as opposed reading and memorizing. There are definitely things I know many aspects of, but I've built that up mostly by building and breaking rather than explicitly trying to commit things to memory.

Collapse
ferricoxide profile image
Thomas H Jones II

Really, it's only worth memorizing things that help you get done the things you currently need to get done. The rest? As long as you know enough to formulate a worthwhile search query and be able to make the results actionable, you're good.

Collapse
vickilanger profile image
Vicki (she/her)

I recently wrote about analysis paralysis. I think you’ve done an awesome job talking about what leads to a constant loop of searching and learning.

Would you mind if I used your ideas to build a talk I’m hoping to give?


Collapse
swarupkm profile image
Swarup Kumar Mahapatra

Memorize the "what is" of everything, instead of "how to" of everything.

Collapse
swiknaba profile image
Lud

Commands that I need at least once per hour are all in my bash_profile with an alias to a short memorable abbreviation. I don't know my abbreviations by hard, but have them in my muscle memory. In case I forgot, I check out my bash profile. Or google it. Works like a charm, and is super fast.

Collapse
nineismine profile image
nineismine

I think the biggest most important thing that we need to work on retaining as a software engineer is ROUGHLY what tools are available, what systems compliment each other and what trends are emerging. I know that this is somewhat bare bones in terms of direction, but to better explain what I mean here I will simply refer to the idea that I hear kicked around pretty often.

Knowing what you don't know :
theemotionmachine.com/wisdom-in-ig...

It is most important for us engineers to keep a tight bead on what we don't know and to continue tirelessly working to expand, enlighten and adapt.

Collapse
jwp profile image
John Peters

In 1985, I took my first IT job working for a defense contactor. They, did very low level software work on Naval Targeting computers. The computers were still in prototype mode where they used emulators that acted as the CPU.

Connected to the emulator was a LED display. The engineers used that panel to punch in op codes. They were progrmming in op codes. This meant they knew all of them, their parameters and output. It must have taken them years. Today, none of that knowledge is relevant. Moral: Be very careful in investing effort into spooky, obscure , unproven, or secret projects.

For me, I take the road closest to the customer, not the deep internals stuff. I read continuously but only dive in after the thing is well established.

Collapse
dipubd profile image
Sudipto Chandra

I follow this rule: Only memorize things that you have looked up three times during my current project, and forget as soon as you are done with it.

Collapse
bugsysailor profile image
Bugsy Sailor

How do you remember if you've looked something up three times? ;)

Collapse
jankapunkt profile image
Jan Küster

Know how to ask questions and you will get good answers.

Collapse
leob profile image
leob

I say OPTION 5 by a long shot ... memorizing is way overvalued, skill, productivity and quality are all that counts, so memorize only what you feel goes toward improving the latter 3. Yes, concepts are what's worth memorizing, but with concepts I'd rather call it "internalizing".

Collapse
jonathands profile image
Jonathan DS

Honestly, I have no idea.

that was quite honest

Collapse
osde8info profile image
Clive Da

dont bother remembering anything just bookmark it (i used to have 10000 bookmarks on delicio.us before it shut down)

Collapse
jenc profile image
jen chan

Hilarious post, and you illustrated a cycle of self pressure and meta anxiety throughout the learning process so well.

Collapse
jcs224 profile image
Joe Sweeney

I don't feel any guilt about looking things up as often as I need to. Over time, if I'm referencing the same material over and over, it will tend to stick eventually.

Collapse
kleene1 profile image
kleene1

You can memorize some stuff, practise is important. Maybe have some files of your previous work.