Back
Felienne Hermans: The Programmer's Brain (Paperback, 2021, Manning Publications) 5 stars

Your brain responds in a predictable way when it encounters new or difficult tasks. This …

Review of "The Programmer's Brain: What every programmer needs to know about cognition" on 'Goodreads'

5 stars

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, python tutor - 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 (le rôle des variables de Sajaniemi 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.