Author: Dr. Felienne Hermans
Publisher: Manning
Date: September 2021
Pages: 256
ISBN: 978-1617298677
Print: 1617298670
Kindle: B09CQHBVQZ
Rating: 4
Reviewer: Mike James
Programmers have a brain - but what is it doing?

This is quite a good book. I enjoyed reading it, but you might not. It all depends what you are expecting. There are lots of things this book is not. It is not a user manual to your programming brain. It wont help you too much with the actual problem of programming and it isn't a list of best practices that give you the practical tools you need to do the job better. What it is is an exploration of what psychology, mostly psycho-physics, can tell us about programming.

The first part of the book is called On Reading Code Better. This starts off with an attempt to classify different kinds of lack of knowledge about t a program that you are trying to understand. This is interesting if not wholly convincing beyond the level of known unknowns and unknown unknowns - obvious and largely unhelpful. The  chapter applies the ideas of short term and long term memory. Again not 100% convincing beyond the obvious. Over the years psychology has had many models of how humans process information and this is just another approach. Why not use information theory to categories the "surprise" contained in the lines of a program under study. There are many possible ways of thinking about things and this is just one. Overall I wasn't convinced by the examples and I'm sure if you program you wont be either.

Chapter 2, speed reading code, covers the difficulties of understanding code. Here we meet ideas that are fairly familiar - chunking, iconic memory and so on. However I'm surprised that it doesn't tackle the real core issue of programming and reading a program. A programmer converts a static representation of a process into a dynamic realization of the process. This is what makes it unique and different from reading say a description of a meeting or a love affair or a ... It is the precision of the realization that is all important and it is what makes it difficult. The chapter and the book in general ignores this idea completely and focuses instead on the idea that reading a program is about comprehension. It is but it is so much more.

The remainder of this section becomes a collection of pop-psychology like recommendations - use flash cards to learn syntax, spaced repetition for remembering and so on. All very reasonable but not deep and fairly familiar if you have read any "how to learn stuff" books. All good, but problems with the syntax of a language are usually the easiest to solve and pale into insignificance compared to other problems. Also it completely ignores that good tools more or less deliver the syntax to you on a plate.

Part 2 is called "On Thinking About Code" and it covers a collection of loosely related topics concerning the readability of code. This for me was the most interesting part of the book because it presented various research results that I'd missed. None of them deep, and none that would change my mind about what makes programming easy or hard - but fun never the less. The classification of what variables do is also interesting but I doubt that there are as many as eleven different roles. There is a section on Hungarian notation and a really interesting discussion of how it is misunderstood - great stuff.

From here things get messy - using models to think about code, notonal machine, why learning a second language is easier and what debugging is about. I found this all too thin to be taken seriously. What else can we do but use models to think about code? Learning a second language is easy because the real skill is in converting a static text into a dynamic process. All computer languages are mostly trivial variations on the basic theme. This said some of the variation happen to be very important and this isn't discussed.  Where is the discussion of object oriented programming? What about functional programming? The real mind bender is probably logic programming but this is not used to illustrate how different things can be - still not very different.

Part 3 is "On Writing Better Code" which is more or less a collection of tips. It covers the problem of naming. Did you know that the most common one letter variable name is "i"? Of course you did - but its fun to see the distribution of other letters - I'll give you a clue "j" is pretty high up on the list!  The rest of the discussion goes beyond the usual "naming is hard" essays an provides some food for thought - however there are no magic solutions. Good naming is still an art barely guided by science.

I found the discussion of code smells and their effects on understanding code unconvincing. We are presented with a list of the originally defined code smells and an analysis of why these might be confusing. To me and I guess most other programmers, code smells has come to mean a code pattern that has a high correlation with some defect. As such I don't think there is a de facto connection between code smells and comprehension. Code smells are bad because they indicate a potential problem with the code not its understanding.

The final part is titled "On Collaborating On Code". This is an area where I have strong views - basically that pair programming is great. This is more or less what the final part says by pointing out its advantages. However I'm not sure a psychology-based justification is needed - you need to try it. Working together on a code base is how the knowledge of that code base can be most easily passed on to novice programmers and it's about time open source projects made it available to get new blood into their projects.

You may wonder why, given I seem to be critical of much of this book, I say I liked reading it? It isn't a book that everyone will find attractive or fun. It is far too detailed and rooted in presenting the results of psychological experiments and then reasonable, but unproven, speculation on how these might throw new light on programming. It tends to treat programming as if it was just the same a reading and writing general text, but of course it is so much more.

This is not a book of solutions to problems that we have. It also ignores much of the environment of modern programming - debuggers, syntax highlighters, intellisense prompting, clever editors, auto-refactoring and so on. Programming isn't the same as it was twenty years ago and if you think it is it is time to catch up.

• Mike James is the author of The Trick Of The Mind: Programming and Computational Thought, aimed at programmers and non-programmers alike, which examines the nature of programming and reveals why it is a very special skill.

To keep up with our coverage of books for programmers, follow @bookwatchiprog on Twitter or subscribe to I Programmer's Books RSS feed for each day's new addition to Book Watch and for new reviews.