To memorize or not to memorize?
scottshipp
Posted on December 7, 2019
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?
Posted on December 7, 2019
Join Our Newsletter. No Spam, Only the good stuff.
Sign up to receive the latest update from our blog.