The programmer's brain - memory and code

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.

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 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 revisit 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 the cognitive refactoring, one of the highlights for me on this section - this was the first time I saw this definition. Therefore, as my personal practice of testing first, I often crossed this path of extracting some temporary code, just to make the test to pass. It helps me on avoiding too much things going around at time. During my practice on the daily basis (while reading the book), I felt that following this approach is much more easy on me during complex tasks.

Also, the memory aids she lists on this part of the book is one of the practices that I will try myself - I did something similar in the past, trying to offload wok on paper or my own notes and it worked like a charm. On the book, she mention Python tutor which is a tool that I never used.

The main take away for this part of the book for me are:

1. Knowing how we categorize the memory and how it behaves
2. Deliberate practice is our friend and spaced repetition is a good practice to keep thing 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 on this section was the misconception that we have in the field around around math, as she mentions the research being done on that matter: Reading texts and reading code are strongly related. As 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 on 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 on 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 practicing on reading code in the formal education that students go through. Usually there is no formal subject in order to sharp reading code skills. Fortunately, Felienne on the book started this discussion. Personally 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 on what professional code looks like, from there, it would be a starting point to train code reading.

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

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

Part 3

Naming

I already wrote a bit about readable code here, therefore, the books used are towards professionals and not that many research involved. On 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 that found, 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 19% increase on finding defects for code that does is not abbreviated. Three steps to chose 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 in 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, 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 a 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 long time
• People cannot multitask
• static-types systems outperform dynamic ones in terms of time and accuracy 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 pin point 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 tem 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