Memorizing Code, PART I

Everyone says you can’t. But you can. Memorization has gotten a bad wrap in favor of “understanding”. In short, the truth is: memorization (or memory) precedes understanding. You Cannot Understand Something That Does Not Exist (at least partially) In Your Memory.

One might memorize the quote “Veni Vidi Vici” without having any understanding of it. They may even use it appropriately by recognizing/recalling the context where they first heard it used. To understand (or know) that “Veni Vidi Vici” means “I came, I saw, I conquered” requires you to know the phrase. You cannot “understand” the words individually unless you had them memorized first; vocabulary precedes grammar.

Taking it a step further: in many cases, one need not even “understand” grammar to understand the actual meaning so long as they have enough vocabulary memorized. While visiting in-laws in Japan, I found that I could “follow” a conversation so long as I could recognize enough memorized words (despite having no “understanding” of the words actually spoken).

TURNING THIS CONCEPT TOWARDS CODE…

To rephrase the above in terms of coding: you cannot “understand” code if you don’t know what the commands represent. You must first have some portion of the programming language you are working with memorized, or at least have the fundamental data structures and patterns memorized so you know what to look for.

In a very minimal example: you don’t need to fully understand how something like .reduce works in order to use it if you’ve seen it used for addition. If you wanted to use it for concatenation then you’d have to have a more “robust” understanding, but it’s the memorizing that comes first.

So, how did I get to this point? And why even try to memorize code?

After spending countless hours struggling through problems/solutions, thinking that I “understood” them, only to come back the following day and again be in essentially the same position, I hit a point of frustration where it occurred to me that it’d be faster (not necessarily easier) to just memorize the damn code; the same way an actor memorizes the lines of a monologue. An initial test allowed me to memorize several simple solutions from educative.io’s Grokking Algorithms course: they were of the sliding window and two pointer variety, one sample looked for the minimum length of an array subsequence that added up to a certain sum, another returned the averages of subsequences of size K, and another would return the largest sum for an array of size K. Another sample looked to see if two items in an array added up to the target sum.

Granted there are much more difficult problems that I have not yet been able to memorize, and memorizing code is a bit harder than dialogue; for dialogue at least “flows logically”. The funny thing about code is: if you understand it, it will flow logically. And, the activity of attempting to memorize code forces you to understand it, and I think (in some ways) understand it moreso than you would if you were just reading a solution. Memorization feels mentally more exhausting than grinding it out in front of the computer, but for the amount of time spent, it seems to be a greater return. Especially since you can copy code snippets onto note cards or origami paper and carry them with you all day.

The “warning” for anyone that tries this (and the current problem I’m facing with this approach) is: that while many algorithms are quite similar (which makes it easy to memorize several snippets at once… especially if they’re almost identical)… well, the problem is: after you memorize five or six, the algorithms start to blend together, they lose their differentiation and becomes a mess, an exercise in rote memory. However, rather than abandon the approach, is to find a way to make it scale. While initially attempting to memorize the code in a “rote” sort of way, I feel that combining the memorization with some universal code analogies, or implementing a “Memory Palace” of the Nelson Dellis or Joshua Foer variety may be the key to a better approach. Having previously attempted to memorize a deck of cards, and being able to get around 27 cards correct (using a memory palace) gives me hope that it’s possible. With that in mind, I feel it’s worth mentioning that a memory palace is not a panacea, for you need to exercise the muscle/visit the palace frequently or it quickly fades.

There will be a PART II to this blog which focuses on my experiment to make use of a “Memory Palace” to better organize code in a memorizable way.


Comments

One response to “Memorizing Code, PART I”

  1. […] Link to Part I, HERE (premise of “Why Memorize”)Link to Part II, HERE (personification of code) […]

Discover more from Comedy Tragedy Epic

Subscribe now to keep reading and get access to the full archive.

Continue reading