The Programmer's Brain

What Hacker News says

1. sltrAug 2025
   Any discussion of cognitive load in programming needs to include awareness of this book:

   The Programmer's Brain: What every programmer needs to know about cognition. By Felienne Hermans

   https://www.manning.com/books/the-programmers-brain

   thread
2. mo_42Aug 2024
   The Programmer's Brain by Felienne Hermans
   thread
3. disposition2Mar 2023
   I have a book club at work where we often read programming / business related books. We're currently reading 'The Programmer's Brain' (which I highly recommend) and thus far the principal argument in the book has been to work on the building blocks / foundation of a language to improve as a developer. I think part of that is by understanding the basics, you will be better able to tackle the difficult things when the time comes.

   It's interesting to see the somewhat conflicting suggestions of this book and the argument that something like ChatGPT / AI can be leveraged to solve the simple problems. We kind of discussed it a bit in the book club. For example, few programmers today worry about assembly / very low level solutions...it's just kind of back of mind / expected to work. I wonder if that will be true for programmers in the future, in relation to the foundation of a particular language. And if so, will the increased usage of AI be a positive or negative thing for the workers in the industry.?

   From what I can tell, management / C-Suite seems to be pretty open to adoption and it's the developers that seem to be a bit more reluctant. Maybe that reluctance is coming from a place of concern about self preservation or maybe it's a valid concern about things like AI hiding / solving some of the fundamentals that allow one to learn the foundations of something...foundational knowledge that might make the more useful for solving the more complex problems.

   I haven't really used AI...so maybe this observation is coming from a place of ignorance. It'll be interesting to see how things work out.

   Show morethread
4. cunningfatalistDec 2022
   The best works of fiction I read:

   - Count Belisarius by Robert Graves

   - The Bone Clocks by David Mitchell

   - The Expanse (all of them)

   - Project Hail Mary by Andy Weir

   And the best books on software development were:

   - Fundamentals of Software Architecture: An Engineering Approach by Mark Richards and Neal Ford

   - Multithreaded JavaScript by Thomas Hunter II and Bryan English

   - The Programmer's Brain by Felienne Hermans

   Show morethread
5. klibertpMay 2022
   "Readability" concept, as commonly understood, is a misnomer - when you say something is readable, you most often mean "it's close to my expectations of how it should be written," regardless of how easy or hard it would be to read. This meaning is very subjective, as there are numerous ways of writing the same thing, and which one you would choose depends on everything you've read and written to date. It's pretty trivial to prove how subjective the notion is: find a few lines of code you think are very readable right now and keep them somewhere, then try to read them a year later. New experiences you've had during the year will, with high probability, change the way you'd write that code, making it less (a bit or more, depending on what you experienced) "readable" to you.

   You can, however, cast readability as a problem in the domain of cognitive science - how easy or hard it is to understand the ideas based on their textual descriptions.

   We more-or-less know how human memory works: there's a working area, short-term memory, long-term memory, and the need to copy data between these segments. The working area is limited in capacity, short-term memory is volatile, and long-term memory is costly to access. In addition, we know that context switches are expensive, and if they last long enough, they can break the flow - or rather, make your working memory reset itself. You then need to reassemble all the pieces required for solving the problem again, from scratch.

   Readability is a score that says how many operations your brain must perform before fully converting the description into understanding. The more readable description requires holding fewer pieces/concepts/ideas in your working memory, minimizes the need for context switches, and doesn't rely on long-term memory too much.

   I felt this would be the case for a long while, but I only recently read a book where most of my suspicions were proved correct. The title is: "The Programmer's Brain - what every programmer should know about cognition," and I can't recommend it enough. It's a bit boring at times, but it provides a good explanation and practical guidelines for writing code that actively supports your cognitive process - or, in other words, is readable.

   One example: to abbreviate or not? Abbreviation may look more readable because it doesn't obscure other nearby identifiers. On the other hand, each time you see an abbreviation, your brain has to expand it, adding to its workload. In this light, you might be tempted to say that we should never abbreviate identifiers. That is not so: other than the brain, between the code and its understanding sits an eye. AbstractFactoryOfConreteFactoryWorkerBean-style identifiers are just as bad as abbreviations, because then your eye has more work to do. So, keep your identifiers not abbreviated as long as you can see the whole identifier in a single glace - start abbreviating after that. Ideally, keep identifiers between 1 and 5 full words.

   The book discusses a lot of similar characteristics of source code, presents empirical studies that back up many of its claims, and in general gives you quite a lot of insight into the mechanics of reading (and writing, but less so) programming languages.

   Show morethread
6. ojintoadMay 2022
   The Programmer's Brain is my favorite read this year, highly recommend

   https://www.manning.com/books/the-programmers-brain

   thread