Okeedoky its a dual-book project now.
Officially decided to take the plunge and memorize Data Structures the Fun Way by Jeremy Kubica.
I’ll be following a similar process to Concepts of Programming Languages, so we’ll see what similarities and differences in scenery and organizational choices I make between the two books.
For Data Structures the Fun Way I’ll start by memorizing the Table of Contents.
I did this with Sebesta’s Concepts of Programming Languages as well.
I like to memorize the Primary Index (in both cases here it’s the Table of Contents) as a separate entity. It gets its own special little reference palace.
Essentially a form of “abstracting”, I suppose.
By keeping a reference index, I “decouple” the palace requirements of the index from the content’s palace requirements.
Or, in other words, if I memorize the Table of Contents, I don’t have to worry about putting together a giant memory palace and then changing it up later when I realize I need more space in some places and less in others.
I just have my Index, and piece by piece I can add additional memory palaces as needed for each section, and I can get very specific about my palace requirements when it matters most: when its time to actually memorize.
For Sebesta’s Concepts book, I memorized the ToC on my fingers and thumbs (not the first palace to use my hands with, I also do binary and subnetting using palaces on my hands).
For Kubica’s Data Structures ToC, I decided to heck with it I’ll use my toes. ![]()
![]()
-I havent memorized it yet, I’ll probably start when I’m done with this post.
The other decision I made for Sebesta’s Concepts is to aggregate the palaces more-or-less in Denton, Texas. A town I know well enough, have plenty of memories in, and still visit on a fairly regular basis.
So, just to get started I memorized all the sections (and subsections and subsubsections) of Chapter 6: Data Structures (in Sebesta’s Concepts of Programming Languages) in a semi-loosey-goosey palace around the courthouse. If you’ve been to Denton, you know the square.
Again, one of the perks of abstracting the Primary Index (the Table of Contents in the case of both of these books) is I can pick and choose any order I want to memorize chapters, as I did here, without worrying about space requirements for all the palaces.
I haven’t selected a primary theme/location to aggregate Kubica’s DStFW yet (like I chose Denton for Sebesta’s Concepts), but golly there’s no need to put the cart before the horse. First I knock out the ToC. The rest will follow.
There are some cool constructs I used for sections and subsections, but I’m sleepy so I’ll cover them later. I’m using one of my favorite techniques, though, which is using shapes as mini-indexes.
How many sides does a shape have? That’s how many items (aka sections) are nested under a given topic. At least that’s one way I like to do it.
For instance, sometimes there’s a nice hexing pentagram/pentagon happening to summon some awful hellspawn like the devil or <insert your favorite politician to despise here>. I instantly know there are 5 items (or sections) contained within whatever imagery is doing the conjuring.
1 item for each side of the pentagram/pentagon.
Triangular shapes represent 3 items, as another example.
Chapter 6’s section titled: Associative Arrays, has 2 subsections.
Each subsection is an opposing team on a Volleyball court (set up impromptu at the Denton Square, at that! Party on!).
To be clear, the fact that there are only 2 “sides” (1 side per team) on a volleyball court is what clarifies how many sections there are. A quickNeasy “checksum” of sorts.
More later,
Beau