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?
Latest comments (26)
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.
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.
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.
Honestly, I have no idea.
that was quite honest
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".
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.
dont bother remembering anything just bookmark it (i used to have 10000 bookmarks on delicio.us before it shut down)
Know how to ask questions and you will get good answers.
You can memorize some stuff, practise is important. Maybe have some files of your previous work.
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.