For Tmux I memorized a cheat sheet of the shortcuts.
I was sitting in the living room when I decided to do it, so I memorized the cheat sheet on my living room windows.
MySQL/MariaDB is another topic from which I memorized a “cheat sheet”.
Cheat sheets are handy for getting a “gist” of something. And occasionally I find one online, in a book, or use an LLM to help me arrange my own.
I utilized an LLM to help design a cheat sheet for git commands. I memorized that on a building in the “industrial” area up the road from me.
If I find myself asking the same question, or looking something up over and over, I usually assume I’ll keep doing it (ie, I’ll keep using extra time “looking up X”). Which I guess is how I give myself permission to just pick an arbitrary “palace” right then and there on the spot—and allot all that future “look up time” to “just memorize it now, Beau, time”.
Another example (I forget how many of these I have) is regular expressions. Which I also memorized in my main living space because that’s where I was sitting when I decided I didn’t want to keep looking it up.
So for the tmux and your window example, can you describe in as much details as you have the time, how you memorized rename window? And vertical split as another example?
And did you divide it up into sessions/pains/window/copy mode? I might as well memorize these things too as I pretty much just now how to split, create a new window, and jump around one window at a time.
Thank you SO MUCH! Also, tmux is a great pilot for me to do this because it’s relatively simple.
Hey,
You made me thinking about memorizing pseudocode to apply logic in different place. I do this all the time, but I never ask myself how.
So I’ve been in the software world for a long time. One think I do automatically is very quickly I learn the codebase of the software I’m working on. I can tell which file and sometime which line of code a bug is before I go there and check. You made thinking about how I do it.
I realize that those place I know them very well when I write tests for it. Mostly every action I do is to run experiment on the system to understand how it react. I go there and write tests which then burn this piece of code in my head as the test is the pseudocode.
This allow me to switch between technology, language without having to learn everything again.
I dont know if can help you in your journey, but wanted to share that understanding the system seems to remove the need of memorization for me :). Also focusing on input/outputs remove the need to know a specific piece of technology as everything become a black box.
Hey, I’m fairly new to memorization techniques, and I was wondering how you managed to memorize such an abstract concept as a programming language and its principles.
Am I correct in assuming you use a memory palace with images that link to concepts? How do you convert these images into remembering technical documentation?
Would you be willing to share just one example of how you do this and what it translates to for you?
I currently have a few memory palaces with about 20 loci each, but they mostly store non-abstract, general facts. For instance, I remember that the hippocampus deals with problem-solving by imagining a hippo solving a puzzle. However, I haven’t yet figured out how to memorize textbooks or more abstract things like formulas, syntax, and programming concepts.
I’m particularly interested in memorizing Python, Linux internals, and CCNA material - mainly for tech interviews, curiosity, and because I’m tired of forgetting everything I read in tech books!
To give an example of what I’m struggling with, I’m completely baffled by how I could translate something like this into a memorable image:
3.3.3.1. Metaclasses
By default, classes are constructed using type(). The class body is executed in a new namespace and the class name is bound locally to the result of type(name, bases, namespace).
The class creation process can be customized by passing the metaclass keyword argument in the class definition line, or by inheriting from an existing class that included such an argument. In the following example, both MyClass and MySubclass are instances of Meta:
class Meta(type): pass class MyClass(metaclass=Meta): pass class MySubclass(MyClass): pass
Any other keyword arguments that are specified in the class definition are passed > through to all metaclass operations described below.
When a class definition is executed, the following steps occur:
MRO entries are resolved;
the appropriate metaclass is determined;
the class namespace is prepared;
the class body is executed;
the class object is created.
What techniques did you use for abstract concepts like this one or something similar? Do you rely on a memory palace with images, or is there something else that works better for you? I’d love to hear one example of how you memorized something like this.
I am not sure what their case is, but I have never found programming to be particularly more abstract than anything else in life. If anything, as I’ve studied it over the last 18 years, it has gotten more concrete and everything else in life has gotten more abstract! Learning to program for me was a series of “oh, this is just how I see the world already”. Maybe this is why I still regularly walk into things.
Or maybe it’s that we choose how we see programming.
You asking @beau2am, but I’m going to pipe up as well about the memorizing abstract info part.
This was one of my first experiments with imaginary palaces.
There is an imaginary place called Python island. It encodes the Python grammar rules.
(Note this is an incomplete palace, but it can show you an idea or two)
You enter Python island on a small jetty.
The jetty ends with 5 4 doors.
Two big ones and three two little ones.
These are the starting grammar production rules.
The one little door is covered in swear word graffiti. Hashes and little symbols like cussing in the comics I read as child.
This is the grammar production rule for F-strings.
(Sadly I see in the latest version of the grammar spec this had been moved somewhere inland. Damn, I liked this door being here.)
The next little door is an “evil” looking door.
This is the grammar production for called eval.
The last small little door is in a funk - it has a little raining cloud over it and everything.
(Makes the door handle wet - super annoying, since that makes it slippery and harder to turn (it’s a round knob))
To be honest, these aren’t the most common doors to enter with. That’s why they are small.
People coming for a quick visit enter through the one large door with a talking face on it - this is the interactive starting rule. This is used in in interactive prompt mode.
The last and most common door is the file door. It has this weird woodwork file as handle. It’s good this door is always open, since the rough raspy surface would be pretty uncomfortable to grasp and pull on.
This is the royal road to Python - it’s for normal Python files.
There’s more to describe here, but let follow where the big doors lead: statement garden.
Before I forget, here is the spec for the jetty and doors:
Now statement garden is all about how statements fit together. This stuff is arranged around a little fountain, but the most important fact about statement garden is that the fountain starts a small river flowing inward into the island.
(Funny isn’t that? Usually rivers flow to the sea. I really need to go explore to figure out why it flows inward, that’s weird and probably significant).
To the one side go simple statement types and to the other side are complex or compound statement types.
Again, the spec:
# GENERAL STATEMENTS
# ==================
statements: statement+
statement: compound_stmt | simple_stmts
statement_newline:
| compound_stmt NEWLINE
| simple_stmts
| NEWLINE
| ENDMARKER
simple_stmts:
| simple_stmt !';' NEWLINE # Not needed, there for speedup
| ';'.simple_stmt+ [';'] NEWLINE
If you spend some time around the fountain - most of his stuff ends up being common sense that you don’t need to fuss about it.
It’s just the fact that you have at least one statement, but probably a lot of them and they are separated by newlines and ended by the end of the file - except where a bunch of them are cramped onto one line with semicolons.
I’d be here all day telling you how to go on from here, but you get the idea.
I haven’t been a good explorer - once you get past the statement types you really get into the weeds. I’ve poked around a bit, but stopped for now. Spending my time with other technologies for now.
Also I haven’t been here recently - not having reviewed it means parts have faded, but yeah.
When I was playing with this for the first time it felt like a total superpower to be able to consider the grammar and its outline completely “offline”.
Why rearrange the island if what you have works and the content isn’t erroneous? The grammar should still be able to be evaluated in your original order, right?
Thanks so much, this really helped me better understand how I could approach it.
I feel the same way - mostly driven by curiosity about whether I can actually do it.
But also believe that memorizing some of the docs would help me - (on top of becoming a more productive programmer) - impress during technical interviews.
As an introvert, I tend to keep my answers brief and then spend the rest of the day regretting all the things I remember that I didn’t say. It would help me give complete responses without missing key details due to nerves.
I just wanted to copy-paste the definition to show what I was describing and saw it had been changed.
It quite cool that I could immediately see what was moved!
What’s interesting is that our memory is already well suited to these kind of changes.
I still remember the little field close to where I live that had sheep in it before it became a small primary school.
I suspect that their refactoring of the grammar itself is worth learning as they will be trying to make it clearer.
@whoismarcel I sure am glad you asked because we all got to read @cedar’s treat of a post as a result!
@cedar, I am totally digging what you was layin’down.
This, for instance!
I have to comment in the least serious admonishment a human bean can muster to do!
Don’t lose it! Keep it! ::billy_mays_face
Methinks it’s sooo much easier to look through the list of language updates, pick the stuff that’s most interesting to me, and memorize a separate index just for them fancy-schmancy language changes.
In them ol’ Information Science books I was reading, the name for: “a publication issued in successive parts” is a “serial.” Harry Potter is a serial, Star Trek (serial TV show), Rolling Stone magazine, School yearbooks, James Bond.
But, when folks go hunting for a serial (as we tend to do when we like something that has more than one version of it), they end up picking one side of the big fat fork in the road called “Do you mean the most recent version, or no?”
Some beautiful loudmouth exclaims “Let’s go watch James Bond!”, we know that lovely fool probably means the Bond, James Bond that just came out.
The cat next to the loudmouth says, “I’d rather reread the Chamber of Secrets by myself at home in a blanket in a box in the garage.”
That cat’ll have to go to the local library’s Harry Potter shrine and look for the specific version of Harry Potter desired (‘Chamber of Secrets’).
Since our fictional library architect already isn’t paid enough they have to choose how to save folks (and themselves) the most time and energy when they go to sifting through series’ of things.
Our architect wears glasses with fake lenses to be cool but is very smart and decides to put the most recent version of James Bond “first” in the series (even though there’s already 79 James Bond movies that came before it).
serial : "a publication issued in successive parts"
serial_examples = [ HarryPotter, StarTrek, RollingStone, 1982 Ridgemont Highschool, JamesBond ]
When the cat drops by and asks for Harry Potter: Chamber of Secrets, the cat doesn’t want the most recent version. And so our architect massages the temples and thinks “did I organize Harry Potter by order in the series, or did I do by alphabetical?..hm…um…”
But then I walk in and interrupt boldly, arrogantly, and smelling faintly of lavender and patchouli while I clack my teeth loudly and rudely “Where’s the Dictionary?”
“AH AN EASY ONE THE DICTIONARY” the librarian exclaims much too excitedly for their own tastes they immediately decide and points you to The Dictionary. Of course, it’s the most recent version, not the 1876 copy some weirdo shouldn’t be out there looking for without a good reason.
But TODAY of all days. The librarian is suddenly accosted by the weirdo.
“Dictionary. English. Eighteen-seventy-six if you don’t mind.”
Let’s hope our librarian remembers where they kept the other versions… wherever they are, they’re probably organized by release date.
Fortunate for us, of course, the Major.Minor.Micro convention exists for software documentation.
Python 'major.minor.micro': <description>
Python 2.6.0 : the last Python 2._._ version published before the "major" update to 3.0 in December of 2008, but 2.6.1 was published the next day.
Python 3.12.7 : last "micro" update to 3.12
Python 3.13.0 : Python 3.12 with a "Minor" update (and current version as of this sentence)
Python 3.13.3 : Three imaginary "micro" updates in the future from now.
Even though, in passing, folks often mean the “latest version of Python” they’ll usually just say “Python,” and layfolk will assume they mean “the most current version.”
But plenty of folks need different versions, so they go hunting for 3.11.3 instead of 3.13.0, or 2.7.18 because dependencies and all that jazz you know this is old news.
All that to say, I adopted the versioning scheme (more or less) and instead of updating all different places the code has changed in the documentation, I just gloss through the “most recent changes”, pick a personally meaningful few, and memorize those like a little “version update” index.
Eventually, once enough time has passed (as it may have for you) I may do a “major” update after some years and “refigure” the organization of my entire palace.
But maybe not. Versioning info can be helpful.
I say you should do that, @cedar! And keep your lovely world intact!
Unless, of course, it’s much more memorable to demolition parts of a palace you’ve grown to know. Obviously then it’s worth changing!
Anyway, gotta run. I wanted to say more but I feel kin with Wonderland’s Rabbit and ‘Look at the time!’
I’ve memorized numerous academic, technical and educational materials, but it dawned on me that this is an opportune time in my own development for me to make the effort to document a process that has become somewhat familiar to me.
So I’ll document this as i go right here on my lil cyber mnemonics journal.
I first mentioned Sebesta’s book back in June when I had recently come across it and figured that, hey, gosh dangit, this might really help in my personal pursuits to dive both deep and long into the “computer sciences” (as the school cats call it).
So far I’ve been programming in:
Javascript
Lua,
Bash,
and of course Python (which by now everyone is quite too aware that I memorized big bunches of the documentation for).
I’ve also been studying C, but have had little reason to write or contribute to anything using C yet. Although Neomutt is written in C, and so is Python (among a million other things), so, soon.
In fact, every one of the aforementioned languages party’s at C’s place. (Lua’s interpreter is written in ANSI C).
The challenge I’ve recognized for a bit now is that if I continue to memorize more and more language documentation, I’ll consequently be memorizing redundancies between languages.
This is where Concepts of Programming Languages comes in (but it is only one resource of a few others to disambiguate solutions to the challenge).
It’s part of my ongoing effort to build a mnemonic taxonomy regarding the aspects of Information Technology that interest me.
I’ll document my goals, thoughts, challenges, solutions, and failures and adjustments as I continue. Could do me a lotta good.
Currently I have the Table of Contents down pat plus all headings, subheadings, and subsubheadings for Chapter 6: Data Structures.
And while I memorize, I also read and review these and other sections of the book.
Another great resource I’ve memorized from is Jeremy Kubica’s Data Structures the Fun Way.
–which I enjoy reading so much that for a first in my avid comp-sci reading journey (if I don’t count our forum’s wonderful Doug Hoff), I hunted around online to see what else this author had written and then my dad (who lives across the country and I miss him) bought me most of Kubica’s other books as a birthday present. Thanks Dad!
I dig this stuff so much.
I should probably start looking to get my foot entry-level in the IT field somewhere. If you know a cat who’s hiring nerds working remotely from Texas, hit me up.
Also, at this point I’m so happy to have reached the point where the memorizing process is just enjoyable and I do it even to entertain myself in my downtime. It’s a good place to be.
Anyway, documenting my process as I memorize Sebesta’s book. That’s what’s next for this journal.
A book that might really interest you is Programming Language Pragmatics. It’s got university book pricing though. Maybe you could request it from your local library?
I think this is the authors site Programming Language Pragmatics
Usually rivers flow to the sea. I really need to go explore to figure out why it flows inward, that’s weird and probably significant).
Although Neomutt is written in C, and so is Python (among a million other things), so, soon.