Table of Contents
- Quickly reading your code
- The Power of Chunking
- Learn Programming Syntax Quickly
- How to Read Complex Code
- Reaching a deeper understanding of code
- Getting better at solving programming problems
- Misconceptions: Bugs in thinking
- How to get better at naming things
- Avoiding bad code and cognitive load: Two frameworks
- Getting better at solving complex problems
- The act of writing code
- Designing and Improving Larger Systems
- How to onboard new developers
Hey there, buzdies! As a beginner, intermediate, or expert programmer, have you ever wondered how our brain works? Is it different from others or just the same?
Well, while I'm unable to answer that question exactly, Felienne Hermans' book The Programmer's Brain uncovers great insights about the programmer's brain; not just about the programmers but anyone who works with code.
TL;DR: The Programmer's Brain by Felienne Hermans focuses on understanding how our brain works when reading, writing and thinking code and how to do every task related with coding, in a better/quick way, followed by varioous exercises, insights and research outcomes.
This detailed review includes key points mentioned in the book, but to unlock your brain's full potential, I recommend you to read the book "The Programmer's Brain" by Manning Publications, which is offering a 45% Discount for all its publications exclusively for my readers (and yes, you're one of 'em) if you're using below code at the checkout.
💡 Enter this code at the checkout - buzzpy24
Also, I'm giving away 2 free e-books of "The Programmer's Brain", selected randomly from whoever fills out this Google form.
Back to the context— the book mainly covers 4 parts Reading Code, Thinking about Code, Writing Better Code, and collaborating on Code.
Let's see what each part covers.
1. On Reading Code Better 🔍
The book begins with an interesting part— how does our brain read code?
Reading code, ours or others is a core part of programming. According to the book, research indicates that almost 60% of programmers spend time understanding rather than writing code. Code reading is not taught or practiced often, and getting to know code is confusing and hard work. But before teaching how to read code in a better way, this book shows how the brain normally reads code.
It states that when we're reading code, our brain tries to process it while reading, but we're not able to clearly express how it processes the code or what it relies on. And then the book shows 3 types of confusion that may occur when reading a certain program, followed by a practical activity where a certain program is written in 3 different languages and you are to read and understand what happens.
Give yourself a few minutes to deeply inspect these programs. What type of knowledge do you rely on when reading them? How does that differ for the three programs? You might not have the words at this point to express what happens in your brain when you read these programs, but I would guess it will feel differently for each.
After this, we can clarify how we read the code, and why did we get confused. Accordingly, the 3 types of confusion are,
Confusion type 1: Lack of knowledge
Confusion type 2: Lack of information
Confusion type 3: Lack of processing power
Thereafter, the book describes cognitive processes related to programming— STM (Short-term memory), LTM (Long-term memory), and Working Memory in depth. By the end of Chapter 1, you'll be able to express what's happening in your brain while reading a certain program.
Quickly reading your code
The 2nd chapter of this part, "Speed reading for code" first analyzes why reading code quickly is hard, and how to overcome size limits in our memory— Chunnking our code and I love what this chapter covers.
As I mentioned earlier, when it comes to real life, code reading is more important than writing code itself. Thus, reading code clearly affects your programming expertise.(— well, I didn't think about that before). The first section of the chapter is also followed by an activity where you're given a Java program and asked to reproduce it after examining it for 3 minutes, from your memory.
As it sounds, it's not an easy task. The following illustration demonstrates what happened to your brain during the activity.
Source: The Programmer's Brain Book
Then the book uncovers why it's hard to read unfamiliar code, followed by an amazing explanation of the size limit of your short-term memory, and how it needs to collaborate with LTM to overcome its size limitations.
The Power of Chunking
This part is followed by the results of a research conducted by Adried De Groot ("Groot" is pronounced more likely as "Growth" rather than "Root" of "Boot", by the way) to find out why one person can become a great chess player while other players are bound to remain “medium” chess players for their entire lives.
In his first chess experiment, experts and average chess players were asked to remember a chess setup. Expert players were able to recall more pieces than average players.
Source: The Programmer's Brain Book
His conclusion was that the expert players outsmarted average players because expert chess players simply had an STM with a larger capacity than average players.
But his second experiment's outcome was surprising. This time, instead of showing the participants a real chess setup like in experiment 1, he showed them chessboards with randomly placed pieces—and not just a little bit random; the chess pieces were set up in entirely unrealistic configurations. And the outcome: both expert and average players performed equally badly.
That's when De Groot decided to find out how exactly the players remembered the chess setups. It turned out that in both experiments the average players mostly remembered the setups piece by piece. They would try to recall the setups by saying “A rook at A7, a pawn at B5, a king at C8," and so on.
Expert players, on the other hand, recalled the setup, and heavily relied on information stored in their LTM. For example, they might remember “a Sicilian opening, but one knight is two squares to the left.” Remembering the setup like that, of course, is only possible if you know what pieces are used in the Sicilian opening, which is stored in the LTM.
Just in case you're wondering what Sicilian Opening is.
Source: Quora
So what does this have to do with programmers? This means, if you have enough information in your LTM, your STM can easily retrieve relevant information from LTM overcoming its size limitations, ultimately helping you to read (and process) code faster than ever.
In the next chapter, the book will uncover how to store information in your LTM quickly and reliably. The rest of this chapter also includes some more interesting research and activities, but here's a summary.
When you lack enough knowledge in your LTM, you have to rely on low-level reading of code, like letters and keywords. When doing that, you will quickly run out of space in your STM.
When your LTM stores enough relevant information, you can remember abstract concepts like “a for-loop in Java” or “selection sort in Python” instead of the code at a lower level, occupying less space in your STM.
When you read code, it is first stored in the iconic memory. Only a bit of the code is subsequently sent to the STM.
Remembering code can be used as a tool for (self) diagnosis of your knowledge of coding. Because you can most easily remember what you already know, the parts of code that you remember can reveal the design patterns, programming constructs, and domain concepts you are most familiar with.
Code can contain characteristics that make it easier to process, such as design patterns, comments, and explicit beacons.
All the above content is deeply described in the book, I highly recommend giving it a read,
Learn Programming Syntax Quickly
Is it necessary to memorize programming syntax? We have ChatGPT, right?
Many programmers believe that if you do not know a certain piece of syntax, you can just look it up on the internet and that therefore syntax knowledge is not all that important. There are two reasons why “just looking things up” might not be a great solution. The first reason was covered in the previous chapter: what you already know impacts to a large extent how efficiently you can read and understand code. The more concepts, data structures, and syntax you know, the more code you can easily chunk and thus remember and process.
Plus, we don't need to get mad at ChatGPT generating code that is opposite to the code that we asked for and we can code with pleasure knowing that we can exist without AI.
The second reason is that an interruption of your work can be more disruptive than you think. Just opening a browser to search for information might tempt you to check your email or read a bit of news, which may not be relevant to the task at hand. You might also lose yourself in reading detailed discussions on programming websites when you are searching for related information.
Now that it's clear that it's important to remember programming syntax, let's move on.
The book introduces flashcards to learn and remember programming syntax quickly. Flashcards are simply paper cards or Post-Its. One side has a prompt on it—the thing that you want to learn. The other side has the corresponding knowledge on it.
When you use your flashcards regularly, after a while you might start to feel that you know some of the cards well. When this happens, you might want to thin out your set of cards a bit. To keep track of how well you know certain concepts, you can keep a little tally on each card of your right and wrong answers.
Source: "The Programmer's Brain" Book
The rest of the chapter covers How not to forget things, Strengthening your memories, and so on. I wish I could elaborate, but since this is just a "review" of the book, I'm unable to do so.
Let's see what the last chapter of Part 1 has got,
How to Read Complex Code
Sometimes, you'll get to read complex code— complex enough that you can not process it inside your brain. In such cases, you'll have to write down the changing values in the program.
Source: The Programmer's Brain Book
To understand why you sometimes need to offload information, you need to understand the third cognitive process mentioned in the book— The Working Memory.
Working memory vs. STM
Felienne Hermans has compared the STM to the RAM of a computer and the LTM to the hard drive. Following that analogy, the working memory is like the brain’s processor.
The working memory represents the brain’s capacity to think, to form new ideas, and to solve problems.
Source: The Programmer's Brain Book
Like the STM, the working memory is only capable of processing two to six things at a time— this capacity is known as the cognitive load. When you are trying to solve a problem that involves too many elements that cannot be divided efficiently into chunks, your working memory will become “overloaded.”
The rest of Chapter 4 introduces methods to systematically address cognitive load with examples and also the memory aids to use when your working memory is overloaded.
(That's 1.6K words just for the first part of the book, not to mention all that was just a scratch of the book! )
2. On thinking about Code 💭
This part covers thinking about code: how to deeply understand programs and avoid bugs in thinking.
Reaching a deeper understanding of code
In this chapter, the book mentioned something I have never heard about— The roles of the variables framework.
According to professor Jorma Sajaniemi at the University of Eastern Finland, the reason variables are hard to understand is that most programmers do not have a good schema in their LTM to relate variables to. Sajaniemi argues that we tend to use chunks that either encompass too much, like “variable” or “integer,” or are too small, such as a specific variable name like number_of_customers. Instead, programmers need something in between, which motivated him to design the roles of variables framework. A variable’s role indicates what it does within the program.
Sajaniemi argues that with just 11 roles, you can describe almost all variables. Those variable roles are— Fixed Value, Stepper, Flag, Walker, Most recent holder, Most wanted holder, Gatherer, Container, Organizer, Temporary, and Follower.
Must say that ♪I love it that way♫.
Source: The Programmer's Brain Book
According to the book, studies have shown that this framework can help students to mentally process source code and that students who use the roles of variables framework outperform those who do not. One reason it’s so effective is that often a group of roles together characterizes a certain type of program.
For example, a program with a stepper and a most wanted holder value is a search program.
If you want to annotate code to get a better understanding, you can use a set of icons to represent the above 11 variable roles. Felienne Hermans has included his set of icons with examples in the book as well.
Rest of the chapter 5 also covers many useful topics along with interesting research, and practical activities. I'm literally in love with this book!
Getting better at solving programming problems
As the title suggests, this chapter covers getting better at solving problems as a programmer. It suggests the use of models to solve problems.
Models
As the author suggests, Models are simplified representations of reality, and the main goal of a model is to support you in thinking about a problem and ultimately solving it. Models can have various shapes and levels of formality. A rough calculation on the back of a beer mat is a model, but an entity relationship diagram of a software system is also a model.
Models can be a big help in solving problems because they help the LTM identify relevant memories.
Then it comes to Mental Models.
The definition of a mental model that I like best is this one: a mental model creates an abstraction in your working memory that you can use to reason about the problem at hand.
This topic is followed by how to use mental models efficiently when reading code— along with the fork-and-spoon experiment's results conducted by Johnson-Laird.
And then the book uncovers various insights about "Notional Machines". Notional machines are abstract versions of how a real computer functions that are used when explaining programming concepts and reasoning about programming.
If I'm going to explain it further with examples, it's gonna take at least another 700 words so— give it a read yourself!
Misconceptions: Bugs in thinking
I love bugs, as much as I love this chapter!
(I have literally written an article about debugging— check it out if you won't get distracted)
It's true, sometimes those itchy bugs are just missing commas and syntax errors. But the book suggests that more often, those bugs are due to the mistakes in our thinking.
You might not know that a file needs to be closed after use, or you might assume that the programming language closes the file for you automatically, and thus a bug blows up.
But before diving into Bugs in thinking, Felienne Hermans explains why learning a second programming language is easier than learning your first programming language, and how to benefit from your existing programming language.
Misconceptions
The book says that when you are sure your code will work, but it still fails, chances are that you are suffering from a misconception. For a belief to be a misconception, it should be faulty, be held consistently across different situations, and be held with confidence.
Felienne has mentioned a great example of a misconception in programming: New programmers sometimes assume that a variable, like, can only hold one value that cannot be changed. While that assumption might sound absurd to an experienced programmer, there are reasons why assuming that a variable can only hold one value is sensible— this assumption might be transferred from prior knowledge of mathematics, where variables indeed do not change within the scope of a mathematical proof or exercise.
While the rest of the chapter uncovers some common misconceptions about programming, and how to suppress them, here's a summary:
Misconceptions are not always addressed by simply realizing or being told you are wrong. For misconceptions to be fixed, you need a new mental model to replace the old, wrong model.
Even if you have learned a correct model, there is always the risk you will fall back on using the misconception.
Use tests and documentation within a codebase to help prevent misconceptions
And then let's jump into the part 3,
On writing better Code 📝
This part moves our attention to writing better code: how to write understandable code and avoid vague names and code smells.
How to get better at naming things
Fortunately, the above topic is widely discussed among developers and developers ARE getting better at naming things. Thus, I won't go further in this chapter.
The book discusses why naming matters with examples, and different perspectives on naming, and then comes an interesting part— Cognitive aspects of Naming. It's said that Formatting names support our STM, while clear names support our LTM. And also variable names can contain different types of information to help you understand them.
Source: The Programmer's Brain Book
The rest of the chapter discusses many more interesting things such as what types of names are easier to understand, snake case and camel case, the influence of names on bugs, and how to choose better names.
Avoiding bad code and cognitive load: Two frameworks
This chapter uncovers the connection between code smells and cognitive processes, especially cognitive load, and surveys the connection between bad names and cognitive load.
(Well, I accept that I didn't know what "code smells" is but turns out code smells are parts of code that are not structured ideally. Like, very long methods or overly complex switch statements, you know.)
This chapter includes an overview of Fowler’s smells (long method, lazy class, data class, etc) and the levels (method level, codebase level, and class level ) they pertain to with an in-depth explanation of the code smells' levels.
It also includes how to measure cognitive load, using the PaaS scale (not to be confused with the "Platform as a service" abbreviation) along with an exercise.
Phew, that's a lot of words but we still have 4 more chapters, so move on!
Oh by the way, have you seen what a baby penguin looks like?
Getting better at solving complex problems
This chapter uncovers about the "The State Space"— All steps that we could consider while solving a program are called the problem’s state space. When playing tic-tac-toe, all possible fields are the state space.
(It's kinda like the sample space which includes possible outcomes of a certain event- that's another thing anyway)
As an example in programming, when adding a button to a website, all possible JavaScript programs are the state space. It is up to the problem solver to make the right moves or add the right lines of code to reach the start goal.
Source: The Programmer's Brain Book
After introducing what's problem-solving, Hermans answers a question that has long-germinated in my mind— Is problem-solving a cognitive process on its own? He answers this question along with George Pólya's book. His book proposes a “system of thinking” to solve any problem involving three steps:
- Understanding the problem
- Devising a plan
- Carrying out the plan
However, the book states that research has consistently shown that problem-solving is neither a generic skill nor a cognitive process, despite the popularity of generic approaches. There are 2 reasons why,
- You use LTM to solve problems
- It's easier for your brain to carry out familiar problems.
The rest of chapter 10 uncovers many insights A new type of cognitive load(Germane load,) implicit memory, and memories that play a role in problem-solving.
On Collaborating on Code 👥
While the previous parts focused on an individual developer, this part is dedicated to collaborating with other developers.
The act of writing code
In the first section of this chapter, this chapter focuses on five programming activities, what programming tasks you likely do in these activities, and what makes each activity hard.
Source: The Programmer's Brain Book
Each activity is explained in depth and then comes something interesting— Interrupted programmer.
Source: Pinterest
This is a very relatable experience for all of us, and of course, it affects our productivity. Van Solingen has found out that interruptions are common and take 15–20 minutes each. About 20% of a developer’s time is spent on interruptions.
According to the book, It takes about a quarter of an hour to start editing code after an interruption. When interrupted during an edit of a method, programmers could resume their work in less than a minute only 10% of the time.
But the best thing is, this chapter has got us covered. It includes how to better prepare for interruptions with three techniques and an important question has been answered— when to interrupt a programmer and also some thoughts on multitasking.
Designing and Improving Larger Systems
In this chapter, the focus shifts from individual lines of code to the broader aspects of organizing code for better understanding.
Felienne introduces C*ognitive Dimensions of Codebases (CDCB)*, a framework derived from Cognitive Dimensions of Notations (CDN). CDCB allows developers to assess the usability of large codebases and gain insights into how they can be understood and improved.
The chapter further discusses cognitive dimensions of code bases (CDCB) and uses it to examine a codebase to understand how it can be understood and improved. CDCB is especially useful for code written in libraries and frameworks, which other programmers often call rather than adapt. The chapter first discusses each of the dimensions in isolation and then dives into how the different dimensions interact with each other and how we can use them to improve existing codebases.
That's a long way around, thus let's save it to read for later and jump into the last chapter.
How to onboard new developers
Now that looks interesting.
As the title suggests, this chapter is about welcoming new developers or expert developers to an unfamiliar codebase. But first, the book discusses the difference between beginner developers and expert developers, starting with an overview of the four different neo-Piagetian levels for programming.
Source: The Programmer's Brain Book
After an in-depth explanation of the neo-Piagetian level, the author explains the difference between seeing concepts concretely and abstractly, along with some mindblowing insights.
And then comes the part I want every senior developer to read: Activities for a Better Onboarding Process, where he suggests 3 activities that are explained in depth. He suggests limiting tasks to one programming activity, supporting the memory of the onboardee, and reading the code together.
And now, finally, we have come to the end.
That's just a bit of the book!
I agree, this review contained a lot— actually, this is one of the longest articles I've ever written but yet, I did skip a lot of parts of the book. For example, I didn't mention Feitelson’s three-step model for better variable names, the fact that "If you can learn French, you can learn Python", and a lot more interesting facts and insights.
I appreciate you for reading this too-much-detailed review, and since you've read this so far, why not get the book and read it yourself?
The Programmer's Brain - Manning Publications
It's really worth the $40, besides, you can get a 45% discount by using the codebuzzpy24which can give you 18$ off this book which makes it: $22 only.
Oh by the way, I'm also giving away 2 free e-books of "The Programmer's Brain", selected randomly from whoever fills out this Google form.
Until the next article, happy coding!
If you have any suggestions/criticisms (I'm sure that this review is very lengthy and many contain many faults/mistakes), feel free to comment!
Top comments (1)
Wow! I missed this post the first time around. It's excellent! Gonna share this one with the DEV team. 😀
Appreciate you sharing this one with us!