The Cognitive Code Vault: Exploring Memory and the Programmer's Brain

The content here is under the Attribution 4.0 International (CC BY 4.0) license

The Programmer’s Brain is one of the best books I’ve read in 2021. I would say that for me, it opened up a different perspective on reading, writing and understanding code. I already wrote some lines around the process of learning and how it is a subject that interests me (learning how to learn), besides I enjoy reading tech-related books.

In this post, I am going to share the main topics that I picked from the book and try to exercise my brain while I do it. Feel free to leave a comment with any feedback you might have. I will try to keep this post up to date as I find new information that adds to the content.

mindmap
  root((Programmers brain))
    The memory
    Code
        Reading code
        Writing code
        Naming things is important

Note: Felienne recorded a podcast focused on the book on the tech lead journal podcast.

Part 1

The memory

The classification around Working memory, Short-term memory and Long-term memory is familiar to me as this is a vocabulary used in the learning how to learn course, besides that, the magical number seven minus or plus two shows up as well, this is a limitation found in our working memory¹, which Felienne’s book also elaborates on (Interesting enough, this subject is discussed by Alberto on his youtube channel and more recently, Vaughn Vernon and Tomasz Jaskula [1] also reference the limitation of the working memory, in their book, they talk about modularity as being a way to break down complexity and avoid such load while dealing with the business problem).

The introduction for the memory is a carpet that goes along the entire book, which makes the reading experience enjoyable, as I can relate to the problems of forgetting things often. On the other hand, this is known by science and as depicted by the book, the only known medicine for that is spaced intervals and revisiting the content often.

If you were ever wondering why you’ve forgotten a lot of what you learned in college, this is why! Unless you revisit knowledge, or are forced to think about it, you will lose memories.

The programmers’s brain, Felienne Hermans

She also talks about cognitive refactoring, one of the highlights for me in this section - this was the first time I saw this definition. Therefore, as my practice of testing first, I often crossed this path of extracting some temporary code, just to make the test pass. It helps me avoid too many things going around at a time. During my practice daily (while reading the book), I felt that following this approach is much easier for me during complex tasks.

Also, the memory aids she lists in this part of the book are one of the practices that I will try myself - I did something similar in the past, trying to offload work on paper or my notes and it worked like a charm. In the book, she mentions Python Tutor which is a tool that I never had the chance to use.

The main takeaways from this part of the book for me are:

1. Knowing how we categorize memory and how it behaves
2. Deliberate practice is our friend and spaced repetition is a good practice to keep things sharp in the memory
3. Forgetting things is something that will happen
4. Cognitive load is important² - even though this subject is spread across the book, this is something that caught my attention since the beginning

Part 2

Reading code

One of the biggest surprises for me in this section was the misconception that we have in the field around math, as she mentions the research being done on that matter: Reading texts and reading code are strongly related. She elaborates on that and shows research related to the brain that points to the same areas being activated while reading code and natural language.

In this part of the book she also talks about two interesting subjects in the programming world. The first is that research shows we as programmers spend more time on reading code than writing it and the second one is, if that is the case how to become a better reader? The following list is given in her book as a way to get started as a framework for being an effective reader:

• Activating
• Monitoring
• Determining importance
• Inferring
• Visualizing
• Questioning
• Summarizing

An interesting discussion that I think would need more depth is the lack of practice in reading code in the formal education that students go through. Usually, there is no formal subject to sharp reading code skills. Fortunately, Felienne in the book started this discussion. I think besides the 7 categories to become an effective reader, we should also take into account how GitHub helps novices and professionals to get a gist of what professional code looks like, from there, it would be a starting point for training code reading.

The takeaways from this part of the book are:

1. Reading code is a skill needed for developers, but that still is not something that gains attention.
2. Reading code comes with experience
3. There are 3 listed misconceptions, but here the one that caught my attention was that coding is more related to natural language than math

Part 3

Naming

I already wrote a bit about readable code here, therefore, the books used are towards professionals and not that much research involved. In Felienne’s book, she brings the subject of naming under another point of view baked by research:

Also, she lists why naming is important:

• Names make up a large part of the code base
• Names play a role in code reviews
• Names are in the most accessible form of documentation
• Names can serve as beacons

Later in this section she also refers to a researcher who found, that naming in code bases does not improve as the code gets older - For me, one extra point for why naming is important and also hard³.

When you read a name, the name will first be broken up into separate chunks and then sent to the working memory. At the same time, the LTM is searched for information related to the different parts of the variable name. Related information from the LTM is also sent to the working memory.

The programmers’s brain, Felienne Hermans

Sometimes we also think that abbreviation is something that doesn’t matter that much, therefore, she refers a research that points to a 19% increase in finding defects for code that is not abbreviated. Three steps to choosing better naming (exactly representation from the book):

1. Select the concepts to include in the name.
2. Choose the words to represent each concept.
3. Construct a name using these words.

Besides that, a few takeaways from this section that I haven’t written:

• Implicit memories are created by repetition
• There are three phases for learning something new: (cognitive phase, associative phase, autonomous phase)
• Deliberate practice is good for improving specific skill
• Spaced repetition is key for learning

Part 4

Writing code

The last part of the book goes into detail around writing code and collaboration, starting with tips on how to face interruptions. Felienne presents a research by Manuela Züger which developed an interactive light called FlowLight. FlowLight is a device that sits on a programmer’s desk and blinks red or green lights based on the cognitive load - if the programmer is in the zone, the light turns red, and green means that it’s ok to interrupt. If you are wondering why, this is because an interrupted task takes longer to finish compared to an uninterrupted on, this is what research points to.

A few more specific points that I highlight while reading this part are:

• TODO’s in code remain unresolved for a long time
• People cannot multitask
• static-types systems outperform dynamic ones in terms of time and accuracy in finding bugs

Last but not least, the onboard process is also something described in the book, which made me realize how traditional onboard adds cognitive load to newcomers, in the book she goes deeper on the reasons why that is the case, but here I will pinpoint what I found most important.

When onboarding new comers we ask them to perform at least four different activities:

• search
• comprehension
• explore
• increment the code base

When asking to do that the newcomer STM is overloaded dealing with several things at once.

UNDERSTANDING IS A BETTER WELCOME TASK THAN BUILDING

The programmers’s brain, Felienne Hermans, pg 216

She also mentions that reading code as a team collaboratively can help the onboard process, interesting enough, I relate this kind of activity as a mob session (even pair programming helps with this kind of activity).

References

1. [1]V. Vernon and T. Jaskula, Vernon/Jaskula-Strategic Microservices and Monoliths,1/e, 1st edition. Pearson, 2022.

Appendix

Talk at Codurance

Lightning talk going through the parts of the book I found interesting to share.

Footnotes

Related subjects

• “It’s like coding in the dark”: The need for learning cultures within coding teams

• [How to Make Learning as Addictive as Social Media

  Luis Von Ahn

  TED](https://www.youtube.com/watch?v=P6FORpg0KVo)

Changelog

• Apr 05, 2024 - Added mindmap
• Nov 01, 2023 - Added Youtube TED talk to the related subjects section
• Jan 27, 2022 - Added slides from speaker deck (talk at Codurance)
• Dec 20, 2021 - Added link to the podcast recorded with Felienne hosted by The Tech Lead Journal content(brain): adds the tech lead journal