Les avantages de l’apprentissage en public
(gilesthomas.com)- Publier sous forme de résumé ou de tutoriel ce qu’on a appris en étudiant revient à écrire soi-même l’article dont on aurait eu besoin au moment de débuter
- Ne pas s’arrêter au fait d’apprendre une nouvelle technologie et de l’essayer soi-même, mais l’expliquer par écrit, permet d’ancrer plus profondément les connaissances et de faire apparaître les zones de compréhension incomplètes
- Le cas de la différence entre l’appel système
epollet les événements edge-triggered/level-triggered est un exemple resté en mémoire longtemps après en avoir laissé une trace écrite il y a presque 12 ans - D’après Google Search Console, une part importante des visiteurs occasionnels arrive via des requêtes liées à ce type d’articles de synthèse d’apprentissage, et les mots-clés correspondent généralement bien au contenu
- À l’avenir, l’auteur prévoit de publier plus souvent des comptes rendus d’apprentissage au format long dans une catégorie provisoire appelée TIL deep dives, différente des courts billets Today I learned
Écrire l’article qu’on aurait voulu trouver au début
- En écrivant récemment plus souvent sur son blog que d’habitude et en relisant ses archives, l’auteur a réfléchi aux points communs entre les articles dont il est le plus satisfait
- Les bons articles se rapprochent d’écrits qui résument ce qu’on a appris ou qui prennent parfois la forme d’un tutoriel, au fil de l’apprentissage de quelque chose ou de la compréhension de son fonctionnement
- Ce type de texte consiste à écrire soi-même « l’article que j’aurais voulu trouver quand j’ai commencé à apprendre »
Mettre par écrit solidifie la compréhension
- Apprendre de nouvelles choses et, si possible, les essayer soi-même est important pour progresser en tant qu’ingénieur
- Écrire ce qu’on a appris permet aux connaissances de s’ancrer plus profondément
- Le vrai critère d’une bonne compréhension est de pouvoir l’expliquer à un lecteur curieux et exigeant sur le plan intellectuel
- L’article sur l’appel système
epollet la différence entre les événements edge-triggered/level-triggered a été écrit il y a presque 12 ans, mais il est toujours resté en mémoire
Des notes d’apprentissage qui atteignent aussi les autres
- D’après Google Search Console, une grande partie des visiteurs non réguliers arrive via des recherches liées à ce type d’articles de synthèse d’apprentissage
- Les requêtes correspondent bien au contenu des articles concernés, ce qui laisse penser que les visiteurs y trouvent ce qu’ils cherchaient
- Les billets d’apprentissage publiés en public consolident la compréhension personnelle tout en pouvant atteindre, via la recherche, des personnes confrontées à des problèmes similaires
Une catégorie appelée TIL deep dives
- L’auteur prévoit à l’avenir d’augmenter plus consciemment ce type d’articles
- L’expression « le tutoriel que j’aurais aimé que quelqu’un écrive avant que j’apprenne » est trop longue, donc il lui a provisoirement donné le nom de TIL deep dives
- Ces articles sont différents des courts billets « Today I learned » qu’on peut voir sur d’autres blogs
- Ils appartiennent à la même famille que les billets TIL de Simon Willison, mais se rapprochent davantage d’un format long
- Simon Willison gère aussi un sous-domaine TIL dédié
1 commentaires
Avis sur Hacker News
Si on tombe sur ce genre d’article, prévenir son auteur devrait aussi faire partie du réflexe
Il suffit d’envoyer un court mail ou de laisser un commentaire. Derrière quelques célébrités de YouTube, il y a des milliers de personnes qui publient du bon contenu sans jamais savoir qui le voit ni qui leur en est reconnaissant
Du coup, quand je vois un texte ou un travail qui me touche, j’ai pris l’habitude d’envoyer un mail même à des inconnus. En suivant l’exemple de Derek Sivers et patio11, j’ai mis sur mon site une « invitation permanente » bien visible, et quand je reçois de temps en temps un mail du genre « bonjour d’un inconnu d’Internet », ça embellit ma journée ou ma semaine. L’email est vraiment parfait pour les discussions approfondies à rythme lent
https://www.evalapply.org/index.html#standing-invitation
Je n’avais aucune idée qu’il y avait une petite pièce ressemblant à un transistor sous la boîte à gants, et la réparation m’a coûté 50 cents. Si cette personne ne l’avait pas publié, je ne l’aurais jamais su, donc je lui ai envoyé un mot de remerciement
Il s’est avéré que le jeu n’était jamais sorti officiellement, et que la démo distribuée avec d’autres jeux et logiciels en était la seule trace publique. Le développeur avait encore le fichier d’installation, assez petit pour être joint à sa réponse, et il me l’a envoyé. J’ai eu la très forte impression que le fait de lui demander des nouvelles d’un jeu qu’il avait créé plus de vingt ans plus tôt avait vraiment embelli sa journée
Le critère de mes billets TIL suit la même philosophie
Si j’ai d’abord cherché et qu’il m’a quand même fallu des heures pour comprendre un problème, c’est un signal très fort que ça mérite d’être documenté. Un billet récent explique comment faire passer le trafic de scraping de GitHub Actions par un proxy via un nœud de sortie Tailscale : https://til.simonwillison.net/tailscale/tailscale-github-act...
Quelque chose comme : « Simon Willison fait ça extrêmement bien, au point d’avoir un sous-domaine entier dédié à ses TIL »
Chaque fois que je répare quelque chose ou galère sur un problème, j’écris toujours un billet de blog pour moi-même, en reconstituant la solution et en y mettant autant que possible les messages d’erreur exacts et les mots-clés que j’ai utilisés dans mes recherches
En cherchant, je suis tombé sur un post Reddit pertinent [1], puis j’ai vu un GitHub Gist lié, avant de réaliser que c’était moi qui l’avais publié. J’avais complètement oublié que j’avais déjà fait ce travail
[1] https://www.reddit.com/r/NixOS/comments/1dahr3g/steamos_base...
C’était un problème lié à MVC.net, et même si j’avais corrigé le même souci que la question, je ne comprenais pas ce que voulaient dire les réponses marquées « meilleure réponse », ni pourquoi elles étaient pertinentes. J’ai donc simplement décrit ce que j’avais fait pour résoudre le problème, du genre « j’ai cliqué ici, puis j’ai saisi ceci pour correspondre à cela ». Ce n’est que bien plus tard que j’ai compris que ma réponse disait en fait exactement la même chose que les autres, mais elle a continué à recevoir des votes de la part de nombreuses personnes qui, elles aussi, cherchaient encore sans comprendre les connexions quasi magiques entre les bindings, les vues et les composants générés par Visual Studio
Le dernier article que j’ai écrit portait sur la manière de remplacer la batterie d’un babyphone
https://www.michael1e.com/how-to-replace-the-eufy-spaceview-...
Elles ne renvoient ni trafic ni récompense, et ne citent même pas leurs sources ¯_(ツ)_/¯
Comme ça, quand une réponse arrive, la personne suivante pourra la retrouver
Le point probablement le plus important de cette approche, c’est qu’en écrivant soi-même l’article qu’on aurait voulu trouver, il y a de fortes chances qu’il redevienne utile plus tard pour soi-même
Beaucoup de mes articles m’ont resservi des années après leur publication. L’effet s’est encore renforcé depuis que j’ai ajouté une fonction de recherche au site et inclus aussi les billets de microblog
Il m’est déjà arrivé de tomber sur mes propres anciens billets de blog en faisant une recherche
Comme j’en ai parlé sur mon blog en 2019, je m’en sers encore aujourd’hui pour me rafraîchir la mémoire
Cette habitude est devenue pour moi une activité de subsistance. Aujourd’hui, je gagne ma vie en documentant la bureaucratie allemande
J’ai fait une présentation sur le « pourquoi », qui est ensuite devenue un long billet de blog : https://nicolasbouliane.com/projects/all-about-berlin
J’aimerais que davantage de gens fassent cela. Quand je tombe sur des ressources similaires, je prends exprès le temps de remercier leurs auteurs. L’une m’a aidé à traverser la Corée à vélo, une autre à réparer un appareil très spécifique. C’est triste de voir Google, les réseaux sociaux et l’IA exploiter le travail de ces personnes utiles comme une mine à ciel ouvert, en leur retirant toute récompense
Je vais bientôt publier une page web qui rassemble ce que j’ai découvert au prix de nombreux jours de travail faute d’informations disponibles.
Si la publication réelle tarde, c’est parce que j’expérimente une approche plus durable qu’avant. Cela inclut de trouver un moyen de générer de l’argent et de rendre plus difficile le pillage intégral par les crawlers et services « IA » :(
J’ai aussi écrit un texte de suivi pour essayer d’expliquer pourquoi : https://news.ycombinator.com/item?id=43166761
Quand quelqu’un prend le temps d’apprécier mon travail — écrire, cuisiner, développer des outils — je me sens reconnu et ça me remonte vraiment le moral
À l’inverse, quand je publie quelque chose et que ça disparaît dans le vide sans que personne ne le remarque ni ne le célèbre, ça me démoralise. En dix ans avec un compte Medium, j’ai connu les deux, et maintenant je ne peux plus arrêter d’écrire, parce que l’écriture fait partie de mon parcours et que les lecteurs sont changeants. J’accepte ça comme une sorte de conditions générales de la création
La moyenne est sans doute d’environ 1, puisque ceux qui en reçoivent en ont généralement 3 ou 4. Le plus gros shoot de dopamine de mes 19 années de blog, c’était de voir cet article atteindre la première place de la page d’accueil de HN, et il est peu probable que cela se reproduise
Je suis en train d’écrire un billet de blog de ce genre en ce moment même
Depuis quelques mois, je ne publie que des articles sur des choses que j’ai eu du mal à découvrir dans mon domaine, Kubernetes, ou des plongées très approfondies dans la lecture de code de codebases open source
Ce sujet a visé juste, et l’envie d’écrire ce genre de texte grandit de jour en jour. Il faut simplement que je le fasse
En ce moment, je manipule un Microchip PolarFire SoC[1], et je savais déjà qu’il n’y avait pas énormément de documentation côté conception FPGA. Mais Microchip, c’est encore une autre dimension par rapport à Xilinx/AMD, Lattice ou aux outils open source. J’ai dû livrer énormément de batailles pour arriver à faire avancer les choses, et ce n’est que maintenant que j’ai enfin un certain workflow et que je commence à comprendre la puce. Je l’aime bien à présent, et c’est une puce qui vaut le coup d’être essayée dans un budget raisonnable pour quelqu’un qui veut se lancer dans la co-conception matériel-logiciel
Chaque fois que je termine une de ces batailles, je me dis : « bordel, il faut que j’écrive ça quelque part sur un blog. Si ça aide une seule personne à l’avenir, ou même juste mon moi futur, ce sera déjà une grande victoire. » Mais jusqu’à présent, c’est mon côté paresseux et un peu effrayé qui a gagné
J’avais peur de ne pas écrire assez bien en anglais, qui n’est pas ma langue maternelle, peur que ce que j’écris soit évident pour tout le monde et que je sois le seul à m’être battu avec ça, peur qu’un ami tombe dessus par hasard et se moque. Mais peu importe. J’en ai envie, donc je dois le faire
[1] https://www.microchip.com/en-us/development-tool/mpfs-disco-...
La dernière phrase m’a rappelé « Roll the dice » de Charles Bukowski. Il faudrait peut-être que je m’en souvienne un peu plus souvent : https://hellopoetry.com/poem/68266/roll-the-dice/
De nos jours, il y a toujours quelqu’un qui a déjà écrit l’article que j’aurais voulu écrire. Alors j’écris ma version
La plupart de mes premiers billets de blog étaient inspirés par des questions sur des forums publics. Je répondais là-bas, puis j’écrivais un billet de blog, et ensuite j’envoyais le lien de cet article. Mes billets du début des années 2000 en gardent la trace
Par exemple, mon article expliquant comment ouvrir le navigateur en plein écran dans IE5 a eu un succès énorme : https://brajeshwar.com/2002/ie-50-full-screen-from-itself/