I’ve spent a lot of my life thinking about programming, and if you’re reading this book you probably have too. I haven’t spent nearly as much time thinking about thinking, though. The concept of our thought processes and how we interact with code as humans has been important to me, but there has been no scientific study behind it. Let me give you three examples.
I’m the main contributor to a .NET project called Noda Time, providing an alternative set of date and time types to the ones built into .NET. It’s been a great environment for me to put time into API design, particularly with respect to naming. Having seen the problems caused by names that make it sound like they change an existing value, but actually return a new value, I’ve tried to use names that make buggy code sound wrong when you read it. For example, the LocalDate type has a PlusDays method rather than AddDays. I’m hoping that this code looks wrong to most C# developers
date.PlusDays(1);
whereas this looks more reasonable:
tomorrow = today.PlusDays(1);
Compare that with the AddDays method in the .NET DateTime type:
date.AddDays(1);
That looks like it’s just modifying date, and isn’t a bug, even though it’s just as incorrect as the first example.
The second example is also from Noda Time, but it’s not quite as specific. Whereas many libraries try (for good reason) to do all the hard work without developers having to think much, we explicitly want the users of Noda Time to put a lot of thought into their date and time code up front. We try to force users to put thought into what they’re really trying to achieve, with no ambiguity—and then we try to make it easy to express that clearly in the code.
Finally, there’s the one conceptual example of what values variables hold in Java and C# and what happens when you pass an argument to a method. It feels like I’ve been trying to counter the notion that objects are passed by reference in Java for most of my life, and when I do the math, that’s probably the case. I suspect I’ve been trying to help other developers fine-tune their mental models for about 25 years now.
It turns out that how programmers think has been important to me for a long time, but with no science behind it, just guesswork and hard-won experience. This book helps to change that, although it isn’t quite the start of this process for me.
I first came across Felienne Hermans at the NDC conference in Oslo in 2017 when she gave her presentation “Programming Is Writing Is Programming.” My reaction on Twitter says it all: “I need a long time to let it all sink in. But wow. Wow.” I’ve seen Felienne give this presentation (evolving over time, of course) at least three times now and have taken something new out of it each time. Finally there were some cognitive explanations for the things I had been trying to do—and also some surprises that challenged me to tweak my approach.
Alternating reactions of “Ah, that makes sense now!” and “Oh, I hadn’t thought of that!” have been the background rhythm when reading this book. Aside from some immediate practical suggestions such as using flashcards, I suspect the impact of the book will be more subtle. Maybe it’s a little more deliberation about when to put a blank line in code. Maybe it’s a change in the tasks we give to new members of the team, or even just a change in the timing of those tasks. Maybe it’s how we explain concepts on Stack Overflow.
Whatever the impact, Felienne has provided a treasure chest of ideas to think about and to process in working memory and move to long-term memory—thinking about thinking is addictive!
Staff Developer Relations Engineer, Google
When I started to teach children to program about 10 years ago, I quickly realized I didn’t have the faintest idea how people use their brains for anything, especially for programming. While I learned a lot about programming in university, no course in my computer science education had prepared me to think about thinking about programming.
If you followed a computer science program like I did, or if you learned programming by yourself, you most likely did not learn about the cognitive functions of the brain. Therefore, you might also not know how to improve your brain to read and write code in a better way. I certainly did not, but while teaching kids to program, I realized I needed a deeper understanding of cognition. I then set out to learn more about how we think and how we learn. This book is the result of the last few years of me reading books, talking to people, and attending talks and conferences about learning and thinking.
Understanding how your brain works is interesting in its own right, of course, but it also matters for programming. Programming is seen as one of the most demanding cognitive activities there is: you are both solving a problem in an abstract way and manipulating a program, which requires a level of attention that does not come naturally to most people. Missed a space? Error. Miscalculated where to start the array indexing? Error. Misunderstood the precise workings of an already existing code? Error.
There are so many ways in which you can shoot yourself in the foot while programming. As you will see in this book, many of the errors you make are rooted in cognitive issues. For example, missing a space might mean you have not mastered the programming language’s syntax in enough detail. Miscalculating where to index an array might indicate you have wrong assumptions about the code. Misunderstanding existing code could be caused by a lack of skills in how to read code.
The aim of this book is to first help you understand how your brain processes code. Understanding what your brain does when presented with new information will help you be a better programmer because professional programmers are faced with new information often. Once we know how code affects the brain, we will talk about methods to improve your code processing skills.
I fully realize how tremendously lucky I am to be able to complete a book on a topic I love. There are so many things in my life that happened in the exact right way at the exact right moment, without which my life would have been a lot different, and this book certainly would have not been written. Dozens of small and large encounters with amazing people have all contributed to this book and to my career. I want to name a few very important ones.
Marlies Aldewereld first put me on the path of programming and language learning. Marileen Smit taught me enough psychology to write this book. Greg Wilson made the topic of programming education mainstream again. Peter Nabbe and Rob Hoogerwoord set world-class examples of how to be a great teacher. Stefan Hanenberg gave me advice that shaped the trajectory of my research. Katja Mordaunt kickstarted the first ever code reading club. Llewellyn Falco’s thinking on koans shaped my thinking on learning extensively. And Rico Huijbers is my beacon in any storm.
In addition to these people, of course, I need to thank the people at Manning— Marjan Bace, Mike Stephens, Tricia Louvar, Bert Bates, Mihaela Batinić, Becky Reinhart, Melissa Ice, Jennifer Houle, Paul Wells, Jerry Kuch, Rachel Head, Sébastien Portebois, Candace Gillhoolley, Chris Kaufmann, Matko Hrvatin, Ivan Martinović, Branko Latinčić, and Andrej Hofšuster for taking on this vague book idea and making it into something readable and sensible.
To all the reviewers: Adam Kaczmarek, Adriaan Beiertz, Alex Rios, Ariel Gamiño, Ben McNamara, Bill Mitchell, Billy O’Callaghan, Bruno Sonnino, Charles Lam, Claudia Maderthaner, Clifford Thurber, Daniela Zapata Riesco, Emanuele Origgi, George Onofrei, George Thomas, Gilberto Taccari, Haim Raman, Jaume Lopez, Joseph Perenia, Kent Spillner, Kimberly Winston-Jackson, Manuel Gonzalez, Marcin Sęk, Mark Harris, Martin Knudsen, Mike Hewitson, Mike Taylor, Orlando Méndez Morales, Pedro Seromenho, Peter Morgan, Samantha Berk, Sebastian Felling, Sébastien Portebois, Simon Tschöke, Stefano Ongarello, Thomas Overby Hansen, Tim van Deurzen, Tuomo Kalliokoski, Unnikrishnan Kumar, Vasile Boris, Viktor Bek, Zachery Beyel, and Zhijun Liu, your suggestions helped make this a better book.
The Programmer’s Brain is a book for programmers of all levels who want to gain a deeper understanding of how their brains work and how they can improve their programming skills and habits. Code examples in various languages will be shown, including JavaScript, Python, and Java, but you do not need deep knowledge of any of the languages as long as you are comfortable reading source code in programming languages you might not have seen before.
To get the most out of reading this book, you should have experience working in a development team or on larger software systems and onboarding people to a team. We will refer to these types of situations often, and you will gain a deeper understanding if you can relate those to your own experiences. In fact, learning increases when you can connect new information to existing knowledge and experiences, which I cover in this book.
While this book presents many topics from cognitive science, it is ultimately a book meant specifically for programmers. We will always contextualize the workings of the brain with results from studies on programming and programming languages specifically.
This book consists of 13 chapters divided into 4 parts. The chapters should be read in order because they build on each other. Each chapter offers applications and exercises that will help you process the material and understand it more deeply. In some cases, I will ask you to find a code base to perform the exercises on to make sure the context is best for you.
Your daily practice is also a place where the knowledge should be applied. I imagine you can read this book over a prolonged period and apply the lessons from one chapter to your programming practice before you move on to read more chapters:
Chapter 1 examines the three cognitive processes that play a role when programming and how each is associated with its own type of confusion.
Chapter 2 discusses how to quickly read code and get a sense of its workings.
Chapter 3 teaches you how to learn programming syntax and concepts better and more easily.
Chapter 5 shows techniques that help you reach a deeper understanding of unfamiliar code.
Chapter 6 covers techniques to get better at solving programming problems.
Chapter 8 discusses how to select clear variable names, especially across a code base.
Chapter 9 focuses on code smells and the cognitive principles behind them.
Chapter 10 discusses more advanced techniques to solve complex problems.
Chapter 11 covers the act of coding and explores the variety of tasks in programming.
Chapter 13 helps you make the onboarding process of new developers less painful.
This book contains many examples of source code both in numbered listings and in line with normal text. In both cases, source code is formatted in a fixed-width font like this to separate it from ordinary text. Sometimes code is also in bold to highlight code that has changed from previous steps in the chapter, such as when a new feature adds to an existing line of code.
In many cases, the original source code has been reformatted; we’ve added line breaks and reworked indentation to accommodate the available page space in the book. In rare cases, even this was not enough, and listings include line-continuation markers (➥ ). Additionally, comments in the source code have often been removed from the listings when the code is described in the text. Code annotations accompany many of the listings, highlighting important concepts.
Purchase of The Programmer’s Brain includes free access to a private web forum run by Manning Publications where you can make comments about the book, ask technical questions, and receive help from the author and from other users. To access the forum, go to https://livebook.manning.com/#!/book/the-programmers-brain/ discussion. You can also learn more about Manning’s forums and the rules of conduct at https://livebook.manning.com/#!/discussion.
Manning’s commitment to our readers is to provide a venue where a meaningful dialogue between individual readers and between readers and the author can take place. It is not a commitment to any specific amount of participation on the part of the author, whose contribution to the forum remains voluntary (and unpaid). We suggest you try asking the author some challenging questions lest their interest stray! The forum and the archives of previous discussions will be accessible from the publisher’s website as long as the book is in print.
Dr. Felienne Hermans is an associate professor at Leiden University in the Netherlands where she researches programming education and programming languages. She also is a teacher-educator at the teachers’ academy of Vrije Universiteit Amsterdam, specializing in didactics of computer science, and teaches at the Lyceum Kralingen high school in Rotterdam.
Felienne is also the creator of the Hedy programming language for novice programmers and is a host of the Software Engineering Radio podcast, one of the largest podcasts about software on the web.
The figure on the cover of The Programmer’s Brain is captioned “femme Sauvage du Canada,” or native woman of Canada. The illustration is taken from a collection of dress costumes from various countries by Jacques Grasset de Saint-Sauveur (1757-1810), titled Costumes civils actuels de tous les peuples connus, published in France in 1788. Each illustration is finely drawn and colored by hand. The rich variety of Grasset de Saint-Sauveur’s collection reminds us vividly of how culturally apart the world’s towns and regions were just 200 years ago. Isolated from each other, people spoke different dialects and languages. In the streets or in the countryside, it was easy to identify where they lived and what their trade or station in life was just by their dress.
The way we dress has changed since then and the diversity by region, so rich at the time, has faded away. It is now hard to tell apart the inhabitants of different continents, let alone different towns, regions, or countries. Perhaps we have traded cultural diversity for a more varied personal life—certainly for a more varied and fast-paced technological life.
At a time when it is hard to tell one computer book from another, Manning celebrates the inventiveness and initiative of the computer business with book covers based on the rich diversity of regional life of two centuries ago, brought back to life by Grasset de Saint-Sauveur’s pictures.