The Programmer's Brain

Ultimately all problems are human problems and all humans have brains. Understanding how our brains work can be very useful.

The Programmer's Brain

I first heard Felienne talk on a podcast a couple years ago. I found her fascinating. She is a CS professor with an interest in neuroscience. She's studied how we learn and how our brains work and how best to explain CS topics and help students understand code. Best of all, she has condensed it all into a book.

The Basic Model

Her book is based on this model of cognition where we have 3 main parts. There is long-term memory which is like the hard drive of a computer. This stores previous experiences, memories, books you've read, skills you've learned, etc. Then there is short-term memory which is kind of like RAM. This contains details about the current task at hand, like where you left your car keys. It's important right now in context, but 10 years from now, it won't be that useful, so it is not stored permanently. Working memory is then like the registers inside a CPU. This is where we manipulate ideas and do calculations.

Felienne then goes on to talk about how a lot of the problems we encountered in programming are related to "failures" in one of these areas. When it comes to long-term memory either we don't have any experience to draw on, or we have the experience but have trouble recalling, or we recall the wrong thing or recall something out of context. For both short-term and working memory, the issues generally revolve around buffer overflow. Both of these have a rather small fixed size and it is easy to overwhelm them. The rest of the book is about strategies to work with our brains in order to optimize many of the tasks we do as programmers.


When it comes to learning code, it is mostly about long-term memory. How do we make sure we are storing the correct information? and how do we make it easier to retrieve? Felienne talks about using flash cards and other methods to make storing and retrieving the right data easier. There is also talk about some of the pitfalls of learning a new language. Much of this is related to long-term memory. Often-times we make assumptions based on our previous experience without taking into account the change of context.

Reading Code

When it comes to reading code, we are talking a lot about short-term and working memory. Since both of these can get overwhelmed easily, one of the big topics is chunking, where we take a bunch of related things and move them around together as one chunk. Think of a chunk as a cluster and your short-term memory as a connector pane. If you only have room to pass in 5 things, you could pass 5 integers or you could pass 5 clusters. There is also some discussion of pattern recognition and pulling patterns from long-term memory.

Writing Code

Generally, a line of code is written once and then read many times. Yet as developers, we don't often write code that way. We are often in hurry and do things like try to save keystrokes by using short names and abbreviations that hinder later readability. The book is full of tips on how to write code that is easier for others to read and understand.


Lastly, the book talks about onboarding. How can we take an outsider with no knowledge of our processes or systems and bring them up to speed? It talks about how to avoid overloading their short-term memory. It talks about what kinds of diagrams and documentation are helpful. It also talks about transferring domain knowledge as well as coding knowledge and skills.


If you want to be an effective programmer or manage programmers effectively, you need to read this book. Even if you aren't a programmer, but happen to work in technology, you'll still get a lot from this book. I highly recommend it. The book goes into much more detail on these areas. It really is worth reading.