What do you think?
Rate this book
The Programmer's Brain
Your brain responds in a predictable way when it encounters new or difficult tasks. This unique book teaches you concrete techniques rooted in cognitive science that will improve the way you learn and think about code.
In The Programmer’s Brain: What every programmer needs to know about cognition you will learn:
* Fast and effective ways to master new programming languages
* Speed reading skills to quickly comprehend new code
* Techniques to unravel the meaning of complex code
* Ways to learn new syntax and keep it memorized
* Writing code that is easy for others to read
* Picking the right names for your variables
* Making your codebase more understandable to newcomers
* Onboarding new developers to your team
Learn how to optimize your brain’s natural cognitive processes to read code more easily, write code faster, and pick up new languages in much less time. This book will help you through the confusion you feel when faced with strange and complex code, and explain a codebase in ways that can make a new team member productive in days!
about the technology
Understanding the cognitive functions that govern the way your brain thinks about coding will help you work smarter, not harder. You’ll improve your productivity, reduce your need for constant rewrites, and say goodbye to spending late nights struggling with new languages.
about the book
The Programmer’s Brain explores the way your brain works when it’s thinking about code. In it, you’ll master practical ways to apply these cognitive principles to your daily programming life. You’ll improve your code comprehension by turning confusion into a learning tool, and pick up awesome techniques for reading code and quickly memorizing syntax. This practical guide includes tips for creating your own flashcards and study resources that can be applied to any new language you want to master. By the time you’re done, you’ll not only be better at teaching yourself—you’ll be an expert at bringing new colleagues and junior programmers up to speed.
In The Programmer’s Brain: What every programmer needs to know about cognition you will learn:
* Fast and effective ways to master new programming languages
* Speed reading skills to quickly comprehend new code
* Techniques to unravel the meaning of complex code
* Ways to learn new syntax and keep it memorized
* Writing code that is easy for others to read
* Picking the right names for your variables
* Making your codebase more understandable to newcomers
* Onboarding new developers to your team
Learn how to optimize your brain’s natural cognitive processes to read code more easily, write code faster, and pick up new languages in much less time. This book will help you through the confusion you feel when faced with strange and complex code, and explain a codebase in ways that can make a new team member productive in days!
about the technology
Understanding the cognitive functions that govern the way your brain thinks about coding will help you work smarter, not harder. You’ll improve your productivity, reduce your need for constant rewrites, and say goodbye to spending late nights struggling with new languages.
about the book
The Programmer’s Brain explores the way your brain works when it’s thinking about code. In it, you’ll master practical ways to apply these cognitive principles to your daily programming life. You’ll improve your code comprehension by turning confusion into a learning tool, and pick up awesome techniques for reading code and quickly memorizing syntax. This practical guide includes tips for creating your own flashcards and study resources that can be applied to any new language you want to master. By the time you’re done, you’ll not only be better at teaching yourself—you’ll be an expert at bringing new colleagues and junior programmers up to speed.
256 pages, Paperback
Published May 1, 2021
158 people are currently reading
1,823 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 80 reviews
June 9, 2021
This book is phenomenal - I'm reeling from its depth and breadth, and will need time to properly digest it. While I've "finished" reading it, I have many notes/highlights/connections to process and thoughts to get out. (This is going to require blog posts). There are also exercises sprinkled throughout the book, from simple thought experiments to pencil-and-paper activities. I expect those to come in handy well into the future.
Some high points that stand out to me:
* Read to understand, code and teach to be understood: I love the focus and clarity that this book brings to reading and understanding code. We learn about cognitive barriers in the way of understanding, and how we can write and teach code in a way that helps understanding.
* Breakdown of memory and cognitive load: The explanation of memory types (short-term, long-term, working) and their role in various programming tasks was useful and interesting. The discussion around "germane cognitive load" (the effort required to store long-term memories) was a particular lightbulb moment.
* Specific words for my feelings: For a good while now, I have used/loved/modified/extended a command-line tool called VisiData. It's been hard for me to put into words what I love about it. Something hand-wavy about the _feel_ of it. Now I have words, thanks to the "Cognitive Dimensions of Notation" section in this book. VisiData has high provisionality (you can think using the tool), low viscosity (it is easy to change), and high progressive evaluation (you can execute incomplete or imperfect code). All of those features are tradeoffs against other dimensions (such as error-proneness), and those tradeoffs make sense in the context of a tool designed for quick and easy exploration.
Some high points that stand out to me:
* Read to understand, code and teach to be understood: I love the focus and clarity that this book brings to reading and understanding code. We learn about cognitive barriers in the way of understanding, and how we can write and teach code in a way that helps understanding.
* Breakdown of memory and cognitive load: The explanation of memory types (short-term, long-term, working) and their role in various programming tasks was useful and interesting. The discussion around "germane cognitive load" (the effort required to store long-term memories) was a particular lightbulb moment.
* Specific words for my feelings: For a good while now, I have used/loved/modified/extended a command-line tool called VisiData. It's been hard for me to put into words what I love about it. Something hand-wavy about the _feel_ of it. Now I have words, thanks to the "Cognitive Dimensions of Notation" section in this book. VisiData has high provisionality (you can think using the tool), low viscosity (it is easy to change), and high progressive evaluation (you can execute incomplete or imperfect code). All of those features are tradeoffs against other dimensions (such as error-proneness), and those tradeoffs make sense in the context of a tool designed for quick and easy exploration.
May 25, 2022
I've been apprehensive about reading The Programmer's Brain since it came out, because it was published around the same time as my own . I was aware that Felienne's aim with her book was likely different than mine, but the thesis that runs through my book is based on how programmers read code, and how the human brain handles that task. I'd based my thesis on the understanding I had, based on books and articles I'd read and podcasts I'd listened to. I hadn't, however, come across a book that explicitly dealt with how the brain interacts with programming.
So I was worried that The Programmer's Brain would invalidate a central thesis in Code That Fits in Your Head. I'm happy to say that it doesn't.
The Programmer's Brain is, in many ways, a survey of what we know about cognition, and how that interacts with reading and writing source code. A central and robust result is that our short-term memory and working memory is quite constrained. Even simple code snippets can easily overload our memory capacity, which Felienne estimates at between 2-6 chunks of information. This I'd already conjectured, although I set the capacity at the magical number 7.
The book also outlines how short-term memory interacts with long-term memory, which is definitely an elaboration I would have loved to have been able to cite. It also contains many ideas about how to deal with brain-unfriendly code, how to learn difficult programming concepts, and how to teach and onboard new team members.
It also reports on how and why bugs are created, based on a clear and distinct definition of what a misconception is. It also covers scientifically sound naming patterns - or moulds, as they are called.
The techniques and findings are all backed by research, and Felienne is honest enough to give us sufficient information about each experiment that we can form our own opinion about it. This is something that I've previously . In short, I find most research in practical software development scientifically shaky. Sample sizes are typically too small, selection bias seems prevalent, and many results rely on subjective judgment (does this particular test outcome go in this or that bucket?).
I understand that research is limited by what's practically possible and economically feasible. Still, we should take research like that reported in this book with a healthy dose of scepticism. Even so, I don't write this because I have a problem with the results being reported. Most of them fit my own understanding of how software development works, so science does, actually, corroborate my previously held beliefs.
It is, however, exactly when the risk of confirmation bias is at its highest that we should be most on guard.
The book can't be faulted for these misgivings - that's just the state of our industry. My only major complaint is rather that it feels a little uneven. Some results (like how constrained our working memory is) are quite universal, while others feel too narrow to be of much interest. Particularly when it comes to some of the advice on how to read code, I get the feeling that it's based on experiments involving toy problems. More than one advice, for example, involves printing out code and annotating it by drawing dependency diagrams. I have trouble seeing how that can work with a typical legacy code base, where lines of code run off to the right for hundreds of characters, and at the same time go on for hundreds of lines.
That said, I find the book an important publication that most programmers should read. Its message is universal - after all, we all run on the same wetware: Brain 1.0.
So I was worried that The Programmer's Brain would invalidate a central thesis in Code That Fits in Your Head. I'm happy to say that it doesn't.
The Programmer's Brain is, in many ways, a survey of what we know about cognition, and how that interacts with reading and writing source code. A central and robust result is that our short-term memory and working memory is quite constrained. Even simple code snippets can easily overload our memory capacity, which Felienne estimates at between 2-6 chunks of information. This I'd already conjectured, although I set the capacity at the magical number 7.
The book also outlines how short-term memory interacts with long-term memory, which is definitely an elaboration I would have loved to have been able to cite. It also contains many ideas about how to deal with brain-unfriendly code, how to learn difficult programming concepts, and how to teach and onboard new team members.
It also reports on how and why bugs are created, based on a clear and distinct definition of what a misconception is. It also covers scientifically sound naming patterns - or moulds, as they are called.
The techniques and findings are all backed by research, and Felienne is honest enough to give us sufficient information about each experiment that we can form our own opinion about it. This is something that I've previously . In short, I find most research in practical software development scientifically shaky. Sample sizes are typically too small, selection bias seems prevalent, and many results rely on subjective judgment (does this particular test outcome go in this or that bucket?).
I understand that research is limited by what's practically possible and economically feasible. Still, we should take research like that reported in this book with a healthy dose of scepticism. Even so, I don't write this because I have a problem with the results being reported. Most of them fit my own understanding of how software development works, so science does, actually, corroborate my previously held beliefs.
It is, however, exactly when the risk of confirmation bias is at its highest that we should be most on guard.
The book can't be faulted for these misgivings - that's just the state of our industry. My only major complaint is rather that it feels a little uneven. Some results (like how constrained our working memory is) are quite universal, while others feel too narrow to be of much interest. Particularly when it comes to some of the advice on how to read code, I get the feeling that it's based on experiments involving toy problems. More than one advice, for example, involves printing out code and annotating it by drawing dependency diagrams. I have trouble seeing how that can work with a typical legacy code base, where lines of code run off to the right for hundreds of characters, and at the same time go on for hundreds of lines.
That said, I find the book an important publication that most programmers should read. Its message is universal - after all, we all run on the same wetware: Brain 1.0.
November 7, 2021
Interesting subject, poorly delivered.
The book seeks to explain the challenges programmers face regularly in reading and remembering code. I love books that take a cognitive science lens to everyday experience. The most important thing in this genre is to provide a framework that resonates with the laypersons experience and is also succinct and applicable.
Unfortunately, this book fails that entirely. It was a struggle to connect with the experiences the author was describing. Once I understood, it felt like the author's framework was less useful than the casual framing one would have with a coworker. I would love to find away with an easily explained framework to help junior engineers in my team but that was not provided.
The book is also extremely wordy. There is a ton of "i will now explain..." and "in the next paragraph we will discuss", "in the prior chapter...", literal pages of it on my Kindle before getting to the content.
The book seeks to explain the challenges programmers face regularly in reading and remembering code. I love books that take a cognitive science lens to everyday experience. The most important thing in this genre is to provide a framework that resonates with the laypersons experience and is also succinct and applicable.
Unfortunately, this book fails that entirely. It was a struggle to connect with the experiences the author was describing. Once I understood, it felt like the author's framework was less useful than the casual framing one would have with a coworker. I would love to find away with an easily explained framework to help junior engineers in my team but that was not provided.
The book is also extremely wordy. There is a ton of "i will now explain..." and "in the next paragraph we will discuss", "in the prior chapter...", literal pages of it on my Kindle before getting to the content.
January 18, 2024
Very interesting book! I wish I had this knowledge in my first years of experience.
In essence, the book talks a little bit about how we learn more generically and adapt those generic concepts to programming.
I think the best insight is that programmers spend more time reading than writing code. I remember the same idea was presented by other authors. I am not sure, but maybe Robert C. Martin in Clean Code and/or Martin Fowler in Refactoring. But this book presented a new perspective on this fact. While other authors argue that given this fact we programmers need to write more readable code, this book argues that given this fact we need to learn (and train) how to read code. I think both ideas are good advice and are complementary.
And this makes a lot of sense in my head. If you want to learn how to write, you need to write but you also need to read a lot. If you want to talk a new language, you need to talk but you also need to listen a lot! But programming courses are almost 100% focused on teach how to write code with almost no attention to how to read code.
I was already convinced by this fact because I think the period of higher growth in my knowledge and career was when I had spent more time doing code reviews. And that is always my advice for junior developers. This book presents a lot of studies that support this idea.
This book also dissect how programming is related to other areas. For example, some studies pointed out that programming is much more related to linguistics than to mathematics. And this is a very relevant information. Maybe we should study spend less time solving logic exercises and spend more time reading, understanding, and refactoring code.
And also provides some theory that can help us to better read code. For example, I never thought about the 11 types of variables. Although I can read and write code without this information, I feel I gained another tool to better read and write code. It is like when you learn syntax analysis in a natural language. You can read and write without knowing what is a verb, a substantive, or an adjective. But to master writing, I think those concepts are essential.
This book also presents good insights about the way of thinking of experts and novices. Sometimes we can think novices are just experts with less context and so they think slowly, but in the same way. This is a huge error. Novices and experts think in totally different ways and knowing the difference is very useful for both parties.
But this book is not perfect. A lot of studies presented are experiments with very small groups so it is hard to believe 100%. And not all practical recommendations make sense to me (but maybe the problem is me and not the book).
Another drawback is that sometimes the book talks a lot about a concept that is not so relevant to the discussion. I think it must be possible to reduce the book by about 50% without losing much relevant information.
In essence, the book talks a little bit about how we learn more generically and adapt those generic concepts to programming.
I think the best insight is that programmers spend more time reading than writing code. I remember the same idea was presented by other authors. I am not sure, but maybe Robert C. Martin in Clean Code and/or Martin Fowler in Refactoring. But this book presented a new perspective on this fact. While other authors argue that given this fact we programmers need to write more readable code, this book argues that given this fact we need to learn (and train) how to read code. I think both ideas are good advice and are complementary.
And this makes a lot of sense in my head. If you want to learn how to write, you need to write but you also need to read a lot. If you want to talk a new language, you need to talk but you also need to listen a lot! But programming courses are almost 100% focused on teach how to write code with almost no attention to how to read code.
I was already convinced by this fact because I think the period of higher growth in my knowledge and career was when I had spent more time doing code reviews. And that is always my advice for junior developers. This book presents a lot of studies that support this idea.
This book also dissect how programming is related to other areas. For example, some studies pointed out that programming is much more related to linguistics than to mathematics. And this is a very relevant information. Maybe we should study spend less time solving logic exercises and spend more time reading, understanding, and refactoring code.
And also provides some theory that can help us to better read code. For example, I never thought about the 11 types of variables. Although I can read and write code without this information, I feel I gained another tool to better read and write code. It is like when you learn syntax analysis in a natural language. You can read and write without knowing what is a verb, a substantive, or an adjective. But to master writing, I think those concepts are essential.
This book also presents good insights about the way of thinking of experts and novices. Sometimes we can think novices are just experts with less context and so they think slowly, but in the same way. This is a huge error. Novices and experts think in totally different ways and knowing the difference is very useful for both parties.
But this book is not perfect. A lot of studies presented are experiments with very small groups so it is hard to believe 100%. And not all practical recommendations make sense to me (but maybe the problem is me and not the book).
Another drawback is that sometimes the book talks a lot about a concept that is not so relevant to the discussion. I think it must be possible to reduce the book by about 50% without losing much relevant information.
June 2, 2022
Un libro excelente para el entender que pasa en nuestro cerebro mientras programamos
En particular me siento como parte de un público atípico para este libro. Mi formación es en Biología (con orientación en Neurociencias) y actualmente me encuentro haciendo un doctorado en Computación.
La autora tiene formación de grado y posgrado en Computación e Ingeniería de Software y el libro apunta a concientizar a gente de ese rubro en temas de Neurociencias (especialmente funciones cognitivas como memoria y atención). Además recorre las (pocas) investigaciones que se han hecho acerca de cómo interactuamos con el código y que prácticas podrían darnos una ventaja.
Resumiendo: El libro es una especie de "Neurociencia para programadores" y en mi caso ya tenía esos conceptos centrales aprendidos. Por esta razón creo que no fui el público objetivo y sin embargo le encontré mucho valor. Creo que puede resultar muy útil para encarar el aprendizaje en etapas más tempranas (sin necesariamente ser una profesional).
Por ejemplo, en el libro se refuerza mucho el valor de la LECTURA de código, en contraposición con la idea de "a codear se aprende codeando", práctica que intuitivamente había encontrado valiosa para mí aprendizaje pero que ahora se ve validada por evidencia.
Finalmente me parece un libro que humaniza mucho el rol de una profesión que sufre de un halo de tecnicismo y plantea cosas interesantes sobre cómo sería la mejor manera de hacer el ingreso (on boarding) de una persona en una empresa sin llevarla a la saturación de sus capacidades mentales.
Recomendado! 😃
En particular me siento como parte de un público atípico para este libro. Mi formación es en Biología (con orientación en Neurociencias) y actualmente me encuentro haciendo un doctorado en Computación.
La autora tiene formación de grado y posgrado en Computación e Ingeniería de Software y el libro apunta a concientizar a gente de ese rubro en temas de Neurociencias (especialmente funciones cognitivas como memoria y atención). Además recorre las (pocas) investigaciones que se han hecho acerca de cómo interactuamos con el código y que prácticas podrían darnos una ventaja.
Resumiendo: El libro es una especie de "Neurociencia para programadores" y en mi caso ya tenía esos conceptos centrales aprendidos. Por esta razón creo que no fui el público objetivo y sin embargo le encontré mucho valor. Creo que puede resultar muy útil para encarar el aprendizaje en etapas más tempranas (sin necesariamente ser una profesional).
Por ejemplo, en el libro se refuerza mucho el valor de la LECTURA de código, en contraposición con la idea de "a codear se aprende codeando", práctica que intuitivamente había encontrado valiosa para mí aprendizaje pero que ahora se ve validada por evidencia.
Finalmente me parece un libro que humaniza mucho el rol de una profesión que sufre de un halo de tecnicismo y plantea cosas interesantes sobre cómo sería la mejor manera de hacer el ingreso (on boarding) de una persona en una empresa sin llevarla a la saturación de sus capacidades mentales.
Recomendado! 😃
September 30, 2021
Si vous avez subi ma progression dans ce livre, vous vous doutez que je suis plutôt enthousiaste ... En vérité, je ne suis pas "plutôt enthousiaste", je pense plutôt que c'est l'un des meilleurs livres imaginables sur le code en tant que media entre humains.
Je vous remets le sommaire avec mes notes d'avancement
PART 1 - ON READING CODE BETTER
1 - Decoding your confusion while coding
Premier chapitre intéressant sur la mémoire à long terme, la mémoire à court terme, et leur âge dans la lecture de code (ainsi que les sources multiples de confusion)
2 - Speed reading for code
La mémoire à long time stocké des concepts, et la mémoire à court terme référence ces concepts. Les développeurs experts ont mémorisé plus de concepts (constructions du ou des langages, design patterns,...) et comprennent donc mieux le code. Mais on peut aider les débutants grâce à des marqueurs (mis clés et /ou commentaires) auxquels accède la mémoire iconique (une forme de mémoire visuelle). Au passage, cette notion de marqueurs qui correspondent aux symboles utilisés par les mémoires à court et long terme me paraît incroyable. Si vous voulez une différence fondamentale entre le cerveau humain et l'ordinateur, en voilà une.
3 - How to learn programming syntax quickly
L'apprentissage de la syntaxe peut utiliser la méthode des répétitions espacées, avec les fiches de mémorisation, mais aussi la réflexion et l'élaboration lors de l'apprentissage.
4 - How to read complex code
On parle de charge cognitive intrinsèque et extrinsèque, et des moyens de comprendre le code lorsqu'il dépasse ces limites en effectuant des refactoring de lisibilité, des graphes de dépendance ou des diagrammes d'état (voire en automatisant ça avec, par exemple, - dont la version Java ne semble pas marcher des tonnes)
PART 2 - ON THINKING ABOUT CODE
5 - Reaching a deeper understanding of code
Des idées pertinents sur la compréhension du code. Certaines sont connues (lire du code est proche du langage naturel). D'autres paraissent curieusement épatantes ( au sujet duquel l'autrice propose carrément un sujet d'emoji rajoutable en overlay, parce qu'inférable depuis le code source). Ça me donne envie de développer un plugin Eclipse !
6 - Getting better at solving programming problems
Où on parle des modèles mentaux que les développeurs utilisent pour découvrir le code, et des machines notionelles, qui sont des modèles mentaux spécifiques appliqués à certains niveaux d'exécution du code.
7 - Misconceptions: Bugs in thinking
Un passage intéressant sur les idées fausses introduites lorsqu'on passe d'un langage à un autre. Des idées fausses qui peuvent évidemment frapper aussi les développeurs débutants, ne disposant pas de modèles internes en nombre suffisant.
PART 3 - ON WRITING BETTER CODE
8 - How to get better at naming things
Il est enfin temps d'écrire du code ! Et la réflexion sur le nommage des variables est bluffante, car tout y passe : abréviations ? Non. Lettres simples ? Non plus. Camel case ou snake case? Camel case. Et même le contenu du nom est étudié. C'est brillant.
9 - Avoiding bad code and cognitive load: Two frameworks
Impressionnant, l'autrice démontre dans cette partie pourquoi les code smells et, pire encore les contre sens linguistiques, sont des obstacles à la compréhension du code.
10 - Getting better at solving complex problems
La résolution de problèmes, en tant que compétence générique, n'existe pas. Et c'est un choc pour moi. Tout comme l'est le fait d'automatiser certaines étapes intellectuelles en les faisant passer de la mémoire cognitive (où on doit réfléchir) à la mémoire associative (où on sait ce qu'il faut faire) puis à la mémoire autonome (où on ne réfléchit plus). C'est exactement l’objectif de toute forme d'entraînement sportif.
PART 4 - ON COLLABORATING ON CODE
11 - The act of writing code
Ecrire du code est une activité complexe, regroupant d'innombrables tâches et activités. ce chapitre essaye de façon convaincante d'en dresser la liste. Et il montre aussi le coût spectaculaire des interruptions. Ce qui me permet une recommandation pour le moi futur : réserver aux développeurs des créneaux sans interruption (oui, ça paraît idiot, mais je pense que ce serait un bon ajout aux "méthodes agiles").
12 - Designing and improving larger systems
L'autrice nous parle des dimensions cognitives du code et de leur impact sur les activités du développeur définies dans le chapitre précédent. C'est vraiment intéressant, parce que ça permet de conditionner le design d'un système logiciel.
13 - How to onboard new developers
Grâce à la comparaison entre experts et débutants, ce chapitre présente quelques suggestions concernant l'onboarding. Et évidement, ce que font traditionnellement les équipes est ... mauvais, juste mauvais. J'ai particulièrement été intéressé par la vision de l'apprentissage sous forme de vague.
En plus d'être un livre franchement accessible, chacun des chapitres est une source d'information à la fois théorique (les résultats des recherches scientifiques y sont exposés avec clarté) et pratique (les conclusions s'appliquent toujours au domaine de l'informatique d'une façon vraiment simple). Franchement, c'est à mon avis une lecture indispensable à tout développeur, ne serait-ce que pour être capable de faire un peu d'introspection sur vos pratiques.
Je vous remets le sommaire avec mes notes d'avancement
PART 1 - ON READING CODE BETTER
1 - Decoding your confusion while coding
Premier chapitre intéressant sur la mémoire à long terme, la mémoire à court terme, et leur âge dans la lecture de code (ainsi que les sources multiples de confusion)
2 - Speed reading for code
La mémoire à long time stocké des concepts, et la mémoire à court terme référence ces concepts. Les développeurs experts ont mémorisé plus de concepts (constructions du ou des langages, design patterns,...) et comprennent donc mieux le code. Mais on peut aider les débutants grâce à des marqueurs (mis clés et /ou commentaires) auxquels accède la mémoire iconique (une forme de mémoire visuelle). Au passage, cette notion de marqueurs qui correspondent aux symboles utilisés par les mémoires à court et long terme me paraît incroyable. Si vous voulez une différence fondamentale entre le cerveau humain et l'ordinateur, en voilà une.
3 - How to learn programming syntax quickly
L'apprentissage de la syntaxe peut utiliser la méthode des répétitions espacées, avec les fiches de mémorisation, mais aussi la réflexion et l'élaboration lors de l'apprentissage.
4 - How to read complex code
On parle de charge cognitive intrinsèque et extrinsèque, et des moyens de comprendre le code lorsqu'il dépasse ces limites en effectuant des refactoring de lisibilité, des graphes de dépendance ou des diagrammes d'état (voire en automatisant ça avec, par exemple, - dont la version Java ne semble pas marcher des tonnes)
PART 2 - ON THINKING ABOUT CODE
5 - Reaching a deeper understanding of code
Des idées pertinents sur la compréhension du code. Certaines sont connues (lire du code est proche du langage naturel). D'autres paraissent curieusement épatantes ( au sujet duquel l'autrice propose carrément un sujet d'emoji rajoutable en overlay, parce qu'inférable depuis le code source). Ça me donne envie de développer un plugin Eclipse !
6 - Getting better at solving programming problems
Où on parle des modèles mentaux que les développeurs utilisent pour découvrir le code, et des machines notionelles, qui sont des modèles mentaux spécifiques appliqués à certains niveaux d'exécution du code.
7 - Misconceptions: Bugs in thinking
Un passage intéressant sur les idées fausses introduites lorsqu'on passe d'un langage à un autre. Des idées fausses qui peuvent évidemment frapper aussi les développeurs débutants, ne disposant pas de modèles internes en nombre suffisant.
PART 3 - ON WRITING BETTER CODE
8 - How to get better at naming things
Il est enfin temps d'écrire du code ! Et la réflexion sur le nommage des variables est bluffante, car tout y passe : abréviations ? Non. Lettres simples ? Non plus. Camel case ou snake case? Camel case. Et même le contenu du nom est étudié. C'est brillant.
9 - Avoiding bad code and cognitive load: Two frameworks
Impressionnant, l'autrice démontre dans cette partie pourquoi les code smells et, pire encore les contre sens linguistiques, sont des obstacles à la compréhension du code.
10 - Getting better at solving complex problems
La résolution de problèmes, en tant que compétence générique, n'existe pas. Et c'est un choc pour moi. Tout comme l'est le fait d'automatiser certaines étapes intellectuelles en les faisant passer de la mémoire cognitive (où on doit réfléchir) à la mémoire associative (où on sait ce qu'il faut faire) puis à la mémoire autonome (où on ne réfléchit plus). C'est exactement l’objectif de toute forme d'entraînement sportif.
PART 4 - ON COLLABORATING ON CODE
11 - The act of writing code
Ecrire du code est une activité complexe, regroupant d'innombrables tâches et activités. ce chapitre essaye de façon convaincante d'en dresser la liste. Et il montre aussi le coût spectaculaire des interruptions. Ce qui me permet une recommandation pour le moi futur : réserver aux développeurs des créneaux sans interruption (oui, ça paraît idiot, mais je pense que ce serait un bon ajout aux "méthodes agiles").
12 - Designing and improving larger systems
L'autrice nous parle des dimensions cognitives du code et de leur impact sur les activités du développeur définies dans le chapitre précédent. C'est vraiment intéressant, parce que ça permet de conditionner le design d'un système logiciel.
13 - How to onboard new developers
Grâce à la comparaison entre experts et débutants, ce chapitre présente quelques suggestions concernant l'onboarding. Et évidement, ce que font traditionnellement les équipes est ... mauvais, juste mauvais. J'ai particulièrement été intéressé par la vision de l'apprentissage sous forme de vague.
En plus d'être un livre franchement accessible, chacun des chapitres est une source d'information à la fois théorique (les résultats des recherches scientifiques y sont exposés avec clarté) et pratique (les conclusions s'appliquent toujours au domaine de l'informatique d'une façon vraiment simple). Franchement, c'est à mon avis une lecture indispensable à tout développeur, ne serait-ce que pour être capable de faire un peu d'introspection sur vos pratiques.
October 26, 2021
It's an amazing book with a very interesting point of view, that will be surely extremely beneficial for beginners, students and juniors, but also for their teachers, mentors and team leaders.
In a way it's a Mind for Numbers for programmers. At least they complement each other.
Unfortunately I am not certain how many of all proposed exercises and workflows can be successfully implemented into a working environment, but at least it should be attempted.
I would like to have some more reading suggestions in this field, or some further reading to improve my code-reading skills.
I decided to share these ideas at work and will give a small talk about the knowledge from this book. I believe it's worth spreading.
In a way it's a Mind for Numbers for programmers. At least they complement each other.
Unfortunately I am not certain how many of all proposed exercises and workflows can be successfully implemented into a working environment, but at least it should be attempted.
I would like to have some more reading suggestions in this field, or some further reading to improve my code-reading skills.
I decided to share these ideas at work and will give a small talk about the knowledge from this book. I believe it's worth spreading.
September 2, 2021
A lot of useful information and studies that helped me to better understand processes that happens while programming / reading the code. I did find some of the examples a little bit dry and exercises could be more concrete (e.g. more detailed case study how to perform some operation on existing code, instead "pick one of your projects and do X"). I also think that the book would be much better if we add more storytelling to that, not just facts and summaries of different researches and publications. I'd love to read more anecdotes, real-world examples from day-to-day life that illustrate different concepts introduced in the book
October 26, 2021
If you're interested in brain cognition through reading, writing and debugging code, this books would be a great fit. Felienne highlights many studies on this matter, listing ways to decrease the load on your brain to free up some compute power to focus on the given problem.
I was not expecting what I found in the book, but it was a pleasant surprise since I am semi-interested in brain cognition.
I was not expecting what I found in the book, but it was a pleasant surprise since I am semi-interested in brain cognition.
March 10, 2023
I expected it to be a dull book, but it actually is a very interesting. I really appreciated that Hermans pointed out that being able to read is more important than being good at logic. I also found the section about the various types of variables very interesting. All in all, I was very pleasantly surprised by this book.
.
.
December 15, 2021
Interesting dive into the cognitive factors that go into learning a programming language or a code base, as well as how those same factors affect the acts of designing and implementing software. I would say that I learned a few things, but for me it was mostly illustrating or giving names to ways that I’ve been working (albeit intuitively) for years. There’s also a sigh of relief there: “Oh it’s fine to feel overwhelmed sometimes � this stuff is HARD!�
August 16, 2022
We read this as part of a book club at my company, and I think this is a great way to absorb and learn this material, together with coworkers! I don't have formal education in cognitive science, so this discussion of how our brains work (or don't work) when programming was really helpful for me in having more structure around how I think about and plan my work.
March 6, 2022
Very interesting book about how your brain behave when learning, understand and the act of writing code.
The book is totally based in short term memory, working memory and long term memory.
The book made me realize how importance is the cognitive load for onboarding new onboarders, we really are biased when passing information and presenting code bass for new comers, but infact we are fully overloading them.
Great book to see our brain perspective when dealing with complex task like software development.
The book is totally based in short term memory, working memory and long term memory.
The book made me realize how importance is the cognitive load for onboarding new onboarders, we really are biased when passing information and presenting code bass for new comers, but infact we are fully overloading them.
Great book to see our brain perspective when dealing with complex task like software development.
March 14, 2022
Good book. Some personal notes:
- Remember code faster with chunk inside LTM, using design pattern, comments, and beacons to create chunks of code.
- Practice reading code: ask why we don't understand the codebase, what's different
- Reading complex code: when you encounter an unfamiliar concept, it is best to try to study it before diving into the code again
- The group who received the recipes do better than the group who had to solve the problems by themselves
- Learning programming doesn't relate to improving logical thinking
- When onboarding a new member, it's better to separate domain learning from exploring code.
- Remember code faster with chunk inside LTM, using design pattern, comments, and beacons to create chunks of code.
- Practice reading code: ask why we don't understand the codebase, what's different
- Reading complex code: when you encounter an unfamiliar concept, it is best to try to study it before diving into the code again
- The group who received the recipes do better than the group who had to solve the problems by themselves
- Learning programming doesn't relate to improving logical thinking
- When onboarding a new member, it's better to separate domain learning from exploring code.
October 31, 2022
Possibly I just love this book because it provides evidence to back up my long-standing, cranky beliefs about things like the importance of reading code (despite its difficulty), the importance of relying on one's own memory rather than looking things up, but I'd say it's an essential read for anyone involved in programming. Each of the parts covers a different aspect of software development, but I found it all thought-provoking, from the naming of variables to onboarding approaches.
Who knows how long the studies this is based on will hold up; when you go back and read empirical studies on programmers, you often find aspects of the methodology that seem questionable or just dated, as the field moves along. But even thinking about some of these aspects of programming in the terms of cognitive science is quite useful, either way.
Who knows how long the studies this is based on will hold up; when you go back and read empirical studies on programmers, you often find aspects of the methodology that seem questionable or just dated, as the field moves along. But even thinking about some of these aspects of programming in the terms of cognitive science is quite useful, either way.
August 11, 2021
Hodnocení pro MEAPV05. O strategiích pro řešení složitějších problémů se nedovíte nic. Kniha psána asi pro jedince s mizernou pamětí a sníženou schopností pochopit i jednoduché zadání, které autor utvrzuje, že je to "normální" a údajně jim nabízí řešení. Spíš ale jde o nevěrohodnou útěchu pro vývojáře - dyslektiky. :) Takto snad pořád průměrný vývojářský mozek nemyslí. Neustálé opakování mantry o třech typech paměti. Jako příklady voleny triviální vývojářské problémy. Ty navíc nejsou uspokojivě (vy) řešeny. Recyklace poznatků ze stejných studií v různých kapitolách knihy.
Knihy od Manningu jsou většinou hodně dobré, tuhle bych ale klidně vynechal.
Knihy od Manningu jsou většinou hodně dobré, tuhle bych ale klidně vynechal.
February 28, 2022
It is a must for every programmer, tech lead or anyone that wants to learn more about why and what you can do to improve your and your colleague's understanding and learnings over knowledge based projects, like software projects ones.
I found some pretty fascinating arguments around "why having a Code Style and a clear architecture" is so important in a project, and also tips to make them more learnable to new members of your team.
Be careful, it is pretty dense, it's full of pretty interesting studies, I think there's so much to learn that just reading it fast would not be a good idea to conceive all that you must from this book.
+99
I found some pretty fascinating arguments around "why having a Code Style and a clear architecture" is so important in a project, and also tips to make them more learnable to new members of your team.
Be careful, it is pretty dense, it's full of pretty interesting studies, I think there's so much to learn that just reading it fast would not be a good idea to conceive all that you must from this book.
+99
January 2, 2022
I wish they taught some of this stuff as part of formal Comp Sci education.
December 1, 2022
в целом прописные истины
April 3, 2022
There are some books which make you feel smarter just by having them on your shelf. This is one of them! I would consider it essential for anyone working with code - whether a wide-eyed newbie or grizzled veteran.
How do human brains understand code? What neurological quirks do we all have? Which common mistakes can be easily avoided? Only by understanding our puny hardware ("Isn’t it a miracle that humans can do anything with no more than 1 byte of memory") can we understand how we should read, write, and think about code.
It is a relatively quick read - I burned through it on a 4 hour flight - but there are lots of practical exercises to do. And it is worth taking the time to think about the process of thinking about code.
Some of the insights are a little obvious - but it is worth spelling them out. For example:
when debugging, many programmers prefer to make small changes to their code (tweaks) and run it again to see if the bug is fixed rather than spending the energy to create a good mental model of the problem
It me! Why do I do that? Why do I think bashing around on a keyboard is more productive than taking 15 minutes to investigate my assumptions about what I'm trying to do - and what the previous programmer was trying to do? The book has answers - and some practical guides for helping you correct your behaviour.
Even "simple" things like naming conventions get a thorough examination, with plenty of academic references:
8.3.2 Snake case or camel case?
The results of Binkley’s study show that the use of camel case leads to higher accuracy among both programmers and non-programmers
8.4.1 Code with bad names has more bugs
Butler’s study found statistically significant associations between naming issues and code quality.
There are lots of footnotes if you want to go wandering into the academic studies - and there are many.
The book - rightly - throws a bit of shade on those of us who have got into bad habits, but haven't reflected on whether they're actually working for us.
11.2.5 Some thoughts on multitasking
The interesting thing is that people who multitask often feel very productive
Ha! True. The book goes into the studies of why people feel the way they do - and whether the data bears out those feelings.
I urge you to read this book. If you are just getting started, it will help you develop good habits. If you're an occasional coder, it will keep you from straying. If you've been doing this for so long that your code is indecipherable to anyone else - it will give you a much-needed reality check.
The book is available in PDF, ePub, and Mobi. At about £25, it's probably worth charging it as a business expense.
Thanks to the publishers for the review copy.
February 24, 2024
Four-and-a-half stars. I found this slim volume quite interesting; whether I will find it useful remains to be seen, but I it has already influenced to some extent how I am naming variables and functions, and how I am mentoring my mentees.
I do find the book's breakdown of memory into Long Term Memory, Short Term Memory and Working Memory, both useful, and suspiciously neat -- our brains don't actually seem to have such bright lines between categories like that in practice. Actually a lot of the categories in this book seem overly neat to me.
The advice given in the book (and there is a lot of it!) seems rather mixed to me. I think memorizing syntax in artificial ways (such as flash cards) doesn't distinguish between common usage and rare usage. I find it more useful to read a book on a language from cover-to-cover, and then go back a look up details as needed. I also find that if I use multiple screens, and I keep the coding screen visible, looking up syntax on-line in another screen doesn't seem to really dump my working memory. But I guess everyone is different.
The book doesn't get into dealing with large code bases until very late (chapter 12 out of 13). This seems odd to me, but since getting out school, in a career now spanning 42+ years, I don't believe I've ever been paid for working on anything but large code bases. Small code bases are something you encounter in student projects or maybe side projects.
The final chapter, on on-boarding new programmers, is a gem -- if for no other reason as the subject is so rarely addressed. Whether the specific advice is actually actionable or not, I will have to see, but the general advice about not sending new programmers into cognitive overload is sound.
A lot of the studies referenced in the book seem either small, or to be pulling on a rather homogeneous pool of subjects, or both, but I suppose they are better than nothing. I was mildly surprised that neither nor Peter Naur's Programming as Theory Building were referenced, since both are seminal in the field (although the author may have felt that Naur is too pessimistic about the possibility for someone who was not involved in coding a system ever fully grasping its model, and thus left him out).
I suspect I will be thinking about the contents of the book for a good while.
I do find the book's breakdown of memory into Long Term Memory, Short Term Memory and Working Memory, both useful, and suspiciously neat -- our brains don't actually seem to have such bright lines between categories like that in practice. Actually a lot of the categories in this book seem overly neat to me.
The advice given in the book (and there is a lot of it!) seems rather mixed to me. I think memorizing syntax in artificial ways (such as flash cards) doesn't distinguish between common usage and rare usage. I find it more useful to read a book on a language from cover-to-cover, and then go back a look up details as needed. I also find that if I use multiple screens, and I keep the coding screen visible, looking up syntax on-line in another screen doesn't seem to really dump my working memory. But I guess everyone is different.
The book doesn't get into dealing with large code bases until very late (chapter 12 out of 13). This seems odd to me, but since getting out school, in a career now spanning 42+ years, I don't believe I've ever been paid for working on anything but large code bases. Small code bases are something you encounter in student projects or maybe side projects.
The final chapter, on on-boarding new programmers, is a gem -- if for no other reason as the subject is so rarely addressed. Whether the specific advice is actually actionable or not, I will have to see, but the general advice about not sending new programmers into cognitive overload is sound.
A lot of the studies referenced in the book seem either small, or to be pulling on a rather homogeneous pool of subjects, or both, but I suppose they are better than nothing. I was mildly surprised that neither nor Peter Naur's Programming as Theory Building were referenced, since both are seminal in the field (although the author may have felt that Naur is too pessimistic about the possibility for someone who was not involved in coding a system ever fully grasping its model, and thus left him out).
I suspect I will be thinking about the contents of the book for a good while.
December 24, 2024
This was a surpassingly interesting book. I expected it to be dry, like most technical books, but the author did a great job of keeping me engaged. While this book targets programmers (like me!), It was fun to read something relevant to my day to day job that is also relevant to life and learning in general.
I especially enjoyed learning about cognitive load and the three different types of memory humans utilize during cognition: long-term memory (LTM), short-term memory (STM), and working memory and how they come into play when reading code.
Below are some of my key takeaways. Note: I'm writing this review months after finishing the book and going on sabbatical, so this review will be limited to the concepts that actually made it into my LTM.
- Why reading really challenging code is so exhausting!
- How to write code (naming conventions, etc), to make code more readable for others. This book presents some interesting history on certain naming conventions (some of them not so good) and how they propagated through the programming community. At least one was based on a misunderstanding.
- Reading unfamiliar code gets easier with practice, so make time to practice. In my experience, its easy to get absorbed in ones own project and not make time to hone unfamiliar code-reading skills. After the initial spin-up on a new project, the opportunities to practice reading unfamiliar code within ones own project generally decrease (depending on the complexity of the project and how much legacy code it contains!). Luckily, there is a virtually unlimited supply of public code out there to leverage for practice.
- Why having a skill that is seemingly similar to a skill one is trying to acquire (for example, having proficiency in 1 or more programming languages and working to learn a new one), comes with some pre-conditioning caveats. The LTM may actually sabotage the effort a bit, by offering up well known tidbits that aren't necessarily applicable. My best personal example of this is having to learn not to insert ; into my python code when switching from C/C++ to python.
- Why we need to be patient with new developers on a project and how to recommend tasks that don't cause cognitive overload. Getting to be the new person on a project must be at least a little bit of a challenge for everyone, but it does get easier with practice. Everyone, especially newer developers, can benefit from not trying to do too much at once.
I especially enjoyed learning about cognitive load and the three different types of memory humans utilize during cognition: long-term memory (LTM), short-term memory (STM), and working memory and how they come into play when reading code.
Below are some of my key takeaways. Note: I'm writing this review months after finishing the book and going on sabbatical, so this review will be limited to the concepts that actually made it into my LTM.
- Why reading really challenging code is so exhausting!
- How to write code (naming conventions, etc), to make code more readable for others. This book presents some interesting history on certain naming conventions (some of them not so good) and how they propagated through the programming community. At least one was based on a misunderstanding.
- Reading unfamiliar code gets easier with practice, so make time to practice. In my experience, its easy to get absorbed in ones own project and not make time to hone unfamiliar code-reading skills. After the initial spin-up on a new project, the opportunities to practice reading unfamiliar code within ones own project generally decrease (depending on the complexity of the project and how much legacy code it contains!). Luckily, there is a virtually unlimited supply of public code out there to leverage for practice.
- Why having a skill that is seemingly similar to a skill one is trying to acquire (for example, having proficiency in 1 or more programming languages and working to learn a new one), comes with some pre-conditioning caveats. The LTM may actually sabotage the effort a bit, by offering up well known tidbits that aren't necessarily applicable. My best personal example of this is having to learn not to insert ; into my python code when switching from C/C++ to python.
- Why we need to be patient with new developers on a project and how to recommend tasks that don't cause cognitive overload. Getting to be the new person on a project must be at least a little bit of a challenge for everyone, but it does get easier with practice. Everyone, especially newer developers, can benefit from not trying to do too much at once.
October 12, 2023
This is a very unique book. Writing (i.e., coding) is the primary operating verb for programmers. Though, writing programs is much less like writing journals, it is more like writing a book that will not only be read a lot, but also will be asynchronously co-written by OTHER authors who may not at all think or write like the original author. Empirically, a piece of code is read 10x more than it is written. This book tries to tie cognitive science to improve BOTH ends of it - how to write programs well so it can be read easily. "Programs must be written for people to read and only incidentally for machines to execute". Most chapters are interesting to read and offers cool analytical insights. As good as they are, it is difficult to find ready applicability-at-scale for most of it.
Some takeaways -
-- Cognitive map has 3 components - short-term (STM), long-term (LTM) and working memory. Rough analogy - LTM is knowledge, STM is input data and working memory is processing.
-- Information in LTM is stored as a connected graph of concepts.
-- Refactoring is mostly about reducing cognitive load.
-- There are 11 types of variables - e.g., flag, most recent holder, most wanted holder, temp etc.
-- Brain scan shows when we read code 5 areas light up in the left hemisphere. All of them are related to natural language processing.
-- Effective reading strategies therefore port to code, namely, activating prior knowledge, monitoring, determining importance, inferring, visualizing, questioning and summarizing.
-- Mental models are essential for us to BOTH work with existing concepts and learn new ones. e.g., Dining philosophers' problem is an excellent mental model to learn the intricacies of concurrent processing.
-- Data structures, architectural and design patterns etc encode abstractions as mental models.
-- High- and Low-road transfer -- Transfer of automatized skills is low-road transfer. e.g., Ctrl-C for copying. Transfer of more complex tasks is high-road - here we are aware of its happening.
-- Near- and Far- transfer, respectively, happen when knowledge transfers in domains that are closer to each other vs. far.
-- "Misconceptions are faulty ways of thinking held with great confidence".
-- A great set of examples of various misconceptions novices hold. e.g., "While loops terminate as soon as condition changes to false".
-- Consistent naming is a big part of writing good code. Code with bad names has more bugs!
-- Code smells creates a lot of cognitive load.
-- "Linguistic antipatterns" map to the "natural language parts of code", e.g., method signature. There are 6 such antipatterns. e.g., "Methods that do more than they say", "methods that say more than they do", "methods that do the opposite of what they say" etc. They create major confusion for the reader.
-- The best part of the book is a framework - "cognitive dimensions" of codebases. The dimensions are - (a) error proneness (e.g., strongly typed languages will have low value here); (b) consistency (IDE helps a lot here); (c) Diffuseness (correlated with code size); (d) hidden dependencies (this, personally, is a terrible side-effect of inheritance, or old-school OOP) etc
Overall, a good and quick read especially for intellectually curious developers/leads. It is also a very rare segment - more is needed in this area, e.g., how to more objectively evaluate "how we write code that can be read better" at scale. Keeping it at 3 stars for lack of immediate applicability at large.
Some takeaways -
-- Cognitive map has 3 components - short-term (STM), long-term (LTM) and working memory. Rough analogy - LTM is knowledge, STM is input data and working memory is processing.
-- Information in LTM is stored as a connected graph of concepts.
-- Refactoring is mostly about reducing cognitive load.
-- There are 11 types of variables - e.g., flag, most recent holder, most wanted holder, temp etc.
-- Brain scan shows when we read code 5 areas light up in the left hemisphere. All of them are related to natural language processing.
-- Effective reading strategies therefore port to code, namely, activating prior knowledge, monitoring, determining importance, inferring, visualizing, questioning and summarizing.
-- Mental models are essential for us to BOTH work with existing concepts and learn new ones. e.g., Dining philosophers' problem is an excellent mental model to learn the intricacies of concurrent processing.
-- Data structures, architectural and design patterns etc encode abstractions as mental models.
-- High- and Low-road transfer -- Transfer of automatized skills is low-road transfer. e.g., Ctrl-C for copying. Transfer of more complex tasks is high-road - here we are aware of its happening.
-- Near- and Far- transfer, respectively, happen when knowledge transfers in domains that are closer to each other vs. far.
-- "Misconceptions are faulty ways of thinking held with great confidence".
-- A great set of examples of various misconceptions novices hold. e.g., "While loops terminate as soon as condition changes to false".
-- Consistent naming is a big part of writing good code. Code with bad names has more bugs!
-- Code smells creates a lot of cognitive load.
-- "Linguistic antipatterns" map to the "natural language parts of code", e.g., method signature. There are 6 such antipatterns. e.g., "Methods that do more than they say", "methods that say more than they do", "methods that do the opposite of what they say" etc. They create major confusion for the reader.
-- The best part of the book is a framework - "cognitive dimensions" of codebases. The dimensions are - (a) error proneness (e.g., strongly typed languages will have low value here); (b) consistency (IDE helps a lot here); (c) Diffuseness (correlated with code size); (d) hidden dependencies (this, personally, is a terrible side-effect of inheritance, or old-school OOP) etc
Overall, a good and quick read especially for intellectually curious developers/leads. It is also a very rare segment - more is needed in this area, e.g., how to more objectively evaluate "how we write code that can be read better" at scale. Keeping it at 3 stars for lack of immediate applicability at large.
May 6, 2022
کتاب جالبی امروز خوندم که بهمون یاد میده موقع مواجه شدن با کد جدید چطور باید بخونیم و درکش کنیم.
نویسنده این کتاب دکتر felienne hermans دانشیار دانشگاه لیدن در هلند هستش و حدود ده سال گذشته را صرف تحقیق در مورد برنامه نویسی، چگونگی یادگیری و نحوه آموزش اون کرده است.
در بخش اول این کتاب بیشتر درباره مغز و نحوه عملکردش توضیح میده، بعد با استفاده از این اطلاعات پایه شروع به یاد دادن تکنیک های مختلف برای خوندن و نوشتن کد میکنه. مغز ما زمانی که با کارهای جدید یا سخت روبرو میشه به یک شیوه ایی که قابل پیش بینی هستش رفتار میکنه.
سه موردی که به اون اشاره شده شامل:
Lack of knowledge = Issue in LTM
Lack of information = Issue in STM
Lack of processing power = Issue in working memory
این کتاب تکنیکهای� را یاد میده که ریشه در علوم شناختی دارند و نحوه یادگیری و تفکر در مورد کد را بهبود میبخشه. یکی از تکنیک های خوبی دربارش صحبت کرده این هستش که چطور فرآیندهای شناختی طبیعی مغز را بهینه کنیم تا کد را راحت تر بخونه، همچنین کمک میکنه از سردرگمی که در مواجهه با کدهای عجیب و پیچیده احساس می کنید، جلوگیری کنه.
موارد دیگه ایی که بهشون اشاره شده شامل:
درک کنید که مغز شما چطور کد را میبینه
روش های سریع و موثر برای تسلط به زبان های برنامه نویسی جدید
یادگیری سینتکس جدید و بخاطر سپردن آن
مهارت تندخوانی برای درک سریع کدهای جدید
تکنیک هایی برای کشف معنای کدهای پیچیده
نوشتن کدی که خوندنش برای دیگران ساده باشه
انتخاب نام مناسب برای متغیرها (این بخش مشابه کتاب clean code هستش)
نویسنده این کتاب دکتر felienne hermans دانشیار دانشگاه لیدن در هلند هستش و حدود ده سال گذشته را صرف تحقیق در مورد برنامه نویسی، چگونگی یادگیری و نحوه آموزش اون کرده است.
در بخش اول این کتاب بیشتر درباره مغز و نحوه عملکردش توضیح میده، بعد با استفاده از این اطلاعات پایه شروع به یاد دادن تکنیک های مختلف برای خوندن و نوشتن کد میکنه. مغز ما زمانی که با کارهای جدید یا سخت روبرو میشه به یک شیوه ایی که قابل پیش بینی هستش رفتار میکنه.
سه موردی که به اون اشاره شده شامل:
Lack of knowledge = Issue in LTM
Lack of information = Issue in STM
Lack of processing power = Issue in working memory
این کتاب تکنیکهای� را یاد میده که ریشه در علوم شناختی دارند و نحوه یادگیری و تفکر در مورد کد را بهبود میبخشه. یکی از تکنیک های خوبی دربارش صحبت کرده این هستش که چطور فرآیندهای شناختی طبیعی مغز را بهینه کنیم تا کد را راحت تر بخونه، همچنین کمک میکنه از سردرگمی که در مواجهه با کدهای عجیب و پیچیده احساس می کنید، جلوگیری کنه.
موارد دیگه ایی که بهشون اشاره شده شامل:
درک کنید که مغز شما چطور کد را میبینه
روش های سریع و موثر برای تسلط به زبان های برنامه نویسی جدید
یادگیری سینتکس جدید و بخاطر سپردن آن
مهارت تندخوانی برای درک سریع کدهای جدید
تکنیک هایی برای کشف معنای کدهای پیچیده
نوشتن کدی که خوندنش برای دیگران ساده باشه
انتخاب نام مناسب برای متغیرها (این بخش مشابه کتاب clean code هستش)
August 27, 2021
There's a large number of studies on how the brain works, and how people learn. This book brings together these studies and suggests techniques and gives you tools to directly apply that learning to programming and software development.
It's worth noting that is does this without diving into agile, or CI/CD. This book is purely about code and the brains that it is understood in, which is refreshing.
I came to this book because I recently realised that not everyone finds naming variables so easy, and are there strategies I can recommend, which are based in some sort of science (which now that I type that out sounds pretty nieche).
What got me really excited though were the strategies for improving chunking and minimising my own cognative load when approaching understanding existing codebases.
If you don't know about the science of how our brains work when you are coding, want to make your own code more understanable, or want strategies in how to understand a complex unfamiliar codebase quickly, then this book is a must read!
The references are great sources too. Discovered a number of new studies I hadn't read yet, which is always a nice surprise.
It's worth noting that is does this without diving into agile, or CI/CD. This book is purely about code and the brains that it is understood in, which is refreshing.
I came to this book because I recently realised that not everyone finds naming variables so easy, and are there strategies I can recommend, which are based in some sort of science (which now that I type that out sounds pretty nieche).
What got me really excited though were the strategies for improving chunking and minimising my own cognative load when approaching understanding existing codebases.
If you don't know about the science of how our brains work when you are coding, want to make your own code more understanable, or want strategies in how to understand a complex unfamiliar codebase quickly, then this book is a must read!
The references are great sources too. Discovered a number of new studies I hadn't read yet, which is always a nice surprise.
March 31, 2022
As someone who has been programming for almost 8 years now, I found this book an interesting read for it's exploration of how the brain words, specifically through the lens of programming. A lot of the cognitive ideas presented were new to me, and some of the exercises (particularly the early ones around copying code from memory) were intriguing as they revealed weaknesses in my programming knowledge that would have otherwise gone unnoticed.
That being said, this book makes a lot of grand claims about being able to change the way you think about code, but I found that it had very little practical application. Many of the frameworks feel like clunky and formal ways to implement techniques that I already use, and some suggestions (like printing out code for manual annotation and using flashcards) felt downright stupid.
As other's have noted, the book could also benefited from a proof read and some removal of fluff, a lot of chapters exist to transplant knowledge from other places (such as a whole chapter that covers code smells through a cognitive lens), overall it was a worthy attempt, but I feel that it could have been better off as a long-format blog post than a book.
That being said, this book makes a lot of grand claims about being able to change the way you think about code, but I found that it had very little practical application. Many of the frameworks feel like clunky and formal ways to implement techniques that I already use, and some suggestions (like printing out code for manual annotation and using flashcards) felt downright stupid.
As other's have noted, the book could also benefited from a proof read and some removal of fluff, a lot of chapters exist to transplant knowledge from other places (such as a whole chapter that covers code smells through a cognitive lens), overall it was a worthy attempt, but I feel that it could have been better off as a long-format blog post than a book.
July 7, 2024
This book uses a lot of research and experiments to demonstrate how the characteristics of our brain memories affect programming activities. The author put together a lot of research and experiments, which shows how much effort was made to write the book. Based on these findings, the book recommends how we can better utilize these characteristics to improve reading/writing code, problem-solving, collaborating with the team, and more.
While the research is pretty interesting, and I think that's where the value of this book lies, the rest of the book seems dull to read. In my opinion, there aren't many actionable items that I can follow. Most of the suggestions are so intuitive that I don't think they need scientific evidence to convince us they work.
The key takeaway, from my point of view, is that there's no magical technique to help us become experts. We need to spend time reading code, following good practices, and planning our tasks in an organized manner.
While the research is pretty interesting, and I think that's where the value of this book lies, the rest of the book seems dull to read. In my opinion, there aren't many actionable items that I can follow. Most of the suggestions are so intuitive that I don't think they need scientific evidence to convince us they work.
The key takeaway, from my point of view, is that there's no magical technique to help us become experts. We need to spend time reading code, following good practices, and planning our tasks in an organized manner.
November 24, 2021
I already had a good base knowledge of Cognitive Load Theory and some of the other models in this book but despite that, I enjoyed reading it!
2 things really stood out for me:
- The direct link to programming: onboarding of new members, reading code, etc. This is just a treasure trove of great advice and hints.
- The immense power of flashcards to support your learning.
I won't tell you much more from the book. If you are a programmer who sometimes struggles to learn something new, this book might tell you more about why you struggle (ex. too much cognitive load?), why it's not your fault (it's just how your brain works), and some tips and tricks towards how you might proceed.
Most of the scientific resources Felienne mentions is linked as a footnote... so if you want to dive a bit deeper into some of the research (which I've done), you can!
2 things really stood out for me:
- The direct link to programming: onboarding of new members, reading code, etc. This is just a treasure trove of great advice and hints.
- The immense power of flashcards to support your learning.
I won't tell you much more from the book. If you are a programmer who sometimes struggles to learn something new, this book might tell you more about why you struggle (ex. too much cognitive load?), why it's not your fault (it's just how your brain works), and some tips and tricks towards how you might proceed.
Most of the scientific resources Felienne mentions is linked as a footnote... so if you want to dive a bit deeper into some of the research (which I've done), you can!
December 1, 2021
An excellent book with clear explanations and a set of concrete techniques to improve how we read, interpret and understand complex code. Each strategy and tool proposed is supported by scientific evidence and the necessary explanation and/or adaptation is given, in a clear way, to use them in software development.
In addition to finding it very useful as a software developer, I consider it a must read for those who teach programming. The science presented and explained in the book helps to improve lessons, to teach our students strategies to learn syntaxis, how to develop software.
It is also very useful to to guide us to find the best materials to accompany the lessons and to generate practical exercises that develop in our students the programming skills and also strategies to continue learning to program.
In addition to finding it very useful as a software developer, I consider it a must read for those who teach programming. The science presented and explained in the book helps to improve lessons, to teach our students strategies to learn syntaxis, how to develop software.
It is also very useful to to guide us to find the best materials to accompany the lessons and to generate practical exercises that develop in our students the programming skills and also strategies to continue learning to program.
November 23, 2022
This book strengthens the connection between the software engineering and cognitive science communities.
This book does not provide new software engineering insights to someone who has read books from the software engineering authors like Kent Beck, Martin Fowler, Robert Martin.
The main contribution of this book however is to present the scientific evidence to the software engineering audience.
Before this book the software engineers had to use phrases like "in my experience", "we believe", "we experience" etc. and this could always be subject to discussion. E.g. someone could always object to it.
After this book, software engineers can use phrases like "scientific evidence shows that" and "this experiment shows that" etc. and this is not so easy to object as it requires a scientific study to be conducted.
This book does not provide new software engineering insights to someone who has read books from the software engineering authors like Kent Beck, Martin Fowler, Robert Martin.
The main contribution of this book however is to present the scientific evidence to the software engineering audience.
Before this book the software engineers had to use phrases like "in my experience", "we believe", "we experience" etc. and this could always be subject to discussion. E.g. someone could always object to it.
After this book, software engineers can use phrases like "scientific evidence shows that" and "this experiment shows that" etc. and this is not so easy to object as it requires a scientific study to be conducted.
Displaying 1 - 30 of 80 reviews
Can't find what you're looking for?
Get help and learn more about the design.