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.

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

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

#career #watercooler #discuss

Vicki Langer

@vicki_langer

Need to come up with a catchy name for my @pycon talk proposal.

Something about:
Loops
Analysis Paralysis
Searching
Learning
Curiousity

15:44 PM - 07 Dec 2019

0 2

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

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.

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.

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

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