5 livres pour changer sa perspective sur le dev

30 Janvier 2023

Les listes de livres pour le dev populaires contiennent peu ou prou les mêmes références. Ces livres sont ennuyeux, voire promeuvent des pratiques toxiques. Laissez-moi vous parler de 5 livres qui peuvent vous changer de perspective sur votre métier.

Designing Data-Intensive Applications par Martin Kleppmann

J'ai déjà eu l'occasion de parler de ce livre ici. C'est peut-être le moins original de la liste. Il couvre les bases pour comprendre les mécanismes derrière les systèmes distribués.

Pour commencer, il rappelle comment les bases de données contournent les limitations pour avoir de bonnes performances. Ensuite il couvrent les systèmes distribués: le partitionnement des données, la réplication. Il en profite pour expliquer les modèles de concurrences. Si tout cela ne vous parle pas et que vous maintenez des systèmes distribués, il y a de fortes chances que vos choix d'architecture soit... hasardeux.

Ce qui me plait dans ce livre c'est qu'il est factuel. Il présente les avantages comme les limites de chaque approche. Les solutions ne sont pas vendues comme des outils magiques, mais comme des solutions pragmatiques à des problèmes. Même le projet sur lequel l'auteur a travaillé, Kafka, est présenté sans vouloir en faire une silver bullet.

Si on devait résumer ce livre en deux mots: pragmatisme et savoir.

Chaos Engineering: System Resiliency in Practice par Casey Rosenthal et Nora Jones

Commençons à rentrer dans l'inhabituel : si notre système est si parfait, montrons-le ! Le livre présente l'historique de la pratique et le processus pour mener le Chaos Engineering. Vous me direz que je me répète vu que j'ai déjà écrit sur ce livre il n'y a pas longtemps. L'originalité de cette approche : elle s'inscrit en direct lignée de la méthode scientifique.

L'approche permet de prendre des décisions renseignées. Ce n'est pas son objectif principal. Elle permet d'avoir plus de connaissances. C'est une excellente approche pour améliorer ce qui est central dans le logiciel : la gestion de la connaissance.

Crafting Interpreters by Robert Nystrom

Ce livre est le plus beau de ma collection. C'est une introduction à l'écriture d'un langage de zéro. Il couvre tous les sujets principaux : du parsing à la machine virtuelle en passant par les optimisations. Il propose d'écrire un langage orienté objet lox de deux façons différentes. Les déclarations, expressions et instructions n'auront plus de secrets !

S'il semble de niche, ce livre contient moult algorithmes qui ne se limitent pas aux interpretateurs. Les problématique de gestion d'erreurs, de simplification du code, de compatibilité sont amplifiées par l'écriture d'un langage. Enfin, ce livre permet de comprendre la difficulté d'implémenter un langage correctement.

Resilient Management by Lara Hogan

Encore un livre dont j'ai déjà parlé ici. À chaque fois que j'entends un dev parler de management, c'est pour exprimer une frustration. Pour certains, cette frustration s'est transformée en haine. On est dans la morale du faible : Je n'ai pas le pouvoir du management, donc je vais tout faire pour lui enlever ce pouvoir.

Pourtant, le rôle du management est crucial dans la réussite d'une équipe. Le bon management permet d'accomplir le meilleur de nous-même. Il permet même de se dépasser et de trouver les opportunités là où on ne les envisageait pas.

Ce petit livre va vous apprendre à savoir quoi attendre de votre manager. Qui sait, ça pourrait même vous donner l'envie de goûter ce rôle ?!

Software Abstractions, Logic, Language, and Analysis par Daniel Jackson

Ce livre vous fera oublier les software crafters. Plutôt que se concentrer sur la syntaxe et la superficielle apparence du code, Daniel Jackson nous offre une perspective nouvelle : si on se concentrait sur ce que programme fait. En nous apprenant à manipuler la modélisation d'algorithmes, on comprend les propriétés de nos programmes. Par propriétés, on entend les états et les comportements qu'un programme peut avoir.

Le livre propose d'apprendre Alloy, mais le principe de base s'applique également à tla+. Une fois qu'on apprend à modéliser un programme, on ne lit plus le code de la même façon. Le code devient un outils pour résoudre un problème, pas une fin en soit. Ainsi, plus besoin de se battre pour savoir si null et undefined sont sémantiquement la même chose. Il suffit de comprendre comment le code réagit à ces valeurs pour vérifier sa validité.

Bonus : Nietzsche

Ces livres sont dans la technique et la technique sans sagesse n'est pas très utile. Bien des développeurs ont un ressentiment à l'encontre du management et du marketing. Beaucoup n'aiment pas le savoir académique, car "pas concret", etc. Or, ce ressentiment se transforme par une médiocrité : celle de se venger en montrant combien le code compte. C'est facile de faire la morale du "bon" ou du "mauvais" code, quand on ne cherche pas à résoudre un problème métier.

Ce paragraphe vous ait peut-être cryptique, je vous invite à regarder ces vidéos pour mieux comprendre :

• Envy par Contrapoint, une vidéo essai sur la toxicité de l'envie
• DANY CALIGULA explique NIETZSCHE en SLIP SARDOCHE ?! par Dany Caligula, qui est moins complet mais en français