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?
Top comments (26)
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 --helpto figure out how to do it.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."
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).
Nice one
You have a really great cheatsheet right there!
Thanks! I'm constantly adding to it as I learn!
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.
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.
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.
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.
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.
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.
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?
Break your Search Loop
Vicki (she/her) ・ Nov 27 ・ 1 min read
Memorize the "what is" of everything, instead of "how to" of everything.