Les livres de prog n'apprennent pas à programmer

J’ai vu un thread Twitter hier. Quelqu’un postait sa pile de bouquins O’Reilly — ‘Learning Python’, ‘Kubernetes: Up and Running’, ‘Designing Data-Intensive Applications’. Des centaines de commentaires pour les féliciter.

Personne demande s’ils ont écrit du Python. Personne demande s’ils ont déployé un pod. Juste des applaudissements pour avoir acheté des livres.

On apprend pas en lisant

Les livres restent sur l’étagère. Le code tourne en prod.

J’ai interviewé des dizaines d’ingénieurs qui ‘ont lu le livre sur Kubernetes’. Quand je leur demande d’écrire un deployment, ils bloquent. Ils connaissent la théorie. Ils savent pas écrire le YAML.

On apprend pas à programmer en lisant. On apprend en cassant des trucs, en les réparant, et en comprenant pourquoi ça a cassé.

Le spectacle que tout le monde joue

Poster sa collection de livres c’est la version tech de ‘je travaille sur moi’. Ça fait productif. Ça signale l’expertise. Mais le signal c’est pas la compétence.

Le vrai apprentissage ressemble à ça:

• Des projets à moitié finis sur ton GitHub
• Des messages d’erreur que t’as mémorisés
• Cet incident prod auquel tu penses encore
• Des questions Stack Overflow auxquelles t’as vraiment répondu

Les livres te donnent pas ça. Casser et réparer des systèmes, oui.

Les livres enseignent les mauvaises choses

La plupart des livres de prog couvrent des fondamentaux que ChatGPT explique mieux en 10 secondes. Le reste c’est de la théorie que tu utiliseras jamais.

Ce dont t’as besoin:

• Comment l’authentification marche vraiment dans ta stack
• Pourquoi ton container est out of memory
• Comment débugger ce problème réseau

Ce que les livres te donnent:

• Des design patterns de 1995
• Des exemples jouets qui compilent mais résolvent rien
• Une couverture exhaustive de features que tu toucheras jamais

Les livres optimisent pour la complétude. Les vrais projets ont besoin de profondeur dans des domaines étroits.

Pratiquer bat consommer passivement

Lire c’est passif. Tu penses comprendre jusqu’à ce que tu essaies de l’implémenter.

Je pensais connaître Docker après avoir lu les docs. Puis j’ai passé une semaine à débugger pourquoi mon image faisait 2GB. Le livre mentionnait les multi-stage builds. Il expliquait pas quand ton cache casse ou pourquoi l’ordre des layers compte.

J’ai appris Docker en:

• Construisant 50 images cassées
• Lisant les messages d’erreur
• Checkant ce que les autres projets faisaient vraiment
• Fixant ce qui cassait en CI

Pas en lisant 400 pages de théorie sur les containers.

Certains livres marchent

Les docs de référence marchent. ‘Voici l’API, voici des exemples’ marche. C’est un outil, pas un manuel scolaire.

Les bouquins techniques profonds marchent quand tu connais déjà les bases. Tu peux pas apprécier ‘Designing Data-Intensive Applications’ avant d’avoir construit quelques applications data-intensive.

Les livres d’architecture marchent si t’as ressenti la douleur qu’ils résolvent. Sinon c’est juste des patterns que tu cargo-cult dans ton code.

Ce qui marche vraiment

Construis quelque chose. Choisis un projet. Fais-le marcher. Rends-le meilleur. Déploie-le. Casse-le. Répare-le.

Lis du code. Pas des livres sur le code. Du vrai code de prod. Regarde quels patterns les vrais ingénieurs utilisent. Regarde ce qu’ils évitent.

Regarde les gens travailler. YouTube a des milliers d’heures d’ingénieurs qui construisent des vrais systèmes. Regarde-les débugger. Regarde-les refactorer. Vois leur processus de pensée.

Fixe de vrais problèmes. Contribuer à l’open source enseigne plus que n’importe quel livre. Tu deals avec de vraies contraintes, de vraies reviews, de vrais users.

Le problème du collectionneur de livres

Je connais des ingénieurs avec des étagères pleines de livres de prog. Aucun d’eux est senior engineer.

Les seniors que je connais:

• Ont 3-4 livres de référence qu’ils ont vraiment utilisés
• Suivent la documentation, pas des manuels
• Apprennent en construisant et cassant
• Lisent le code source quand ils sont perdus

Les livres c’est du comfort food. Ils te font sentir que t’apprends. Mais l’apprentissage se passe dans le terminal, pas sur l’étagère.

Commence maintenant

Ferme cet article. Ouvre ton éditeur. Choisis un truc que tu connais pas. Code-le comme tu peux. Fais-le marcher. Casse-le exprès. Répare-le.

C’est comme ça qu’on apprend.

Les livres c’est pour avoir l’air smart sur Twitter. Le code c’est pour faire avancer les choses.