Le plaisir de créer des logiciels-jouets

• Créer des logiciels-jouets est une façon de retrouver le plaisir et la créativité qui sont au cœur du développement logiciel
• À une époque où l’IA et l’industrialisation font disparaître la joie pure du développement logiciel, réaliser de petits programmes-jouets comme projets personnels permet d’acquérir des connaissances utiles en pratique et une compréhension plus profonde
• Les logiciels-jouets suivent la règle du 80:20 : obtenir un maximum de fonctionnalités avec un minimum de code, et l’essentiel est d’éviter la surconception et l’obsession de la finition
• Sans dépendre d’outils d’IA comme les LLM, l’expérience même de construire par soi-même, en se confrontant directement aux difficultés, constitue le vrai plaisir de l’apprentissage et de la progression

---

Pourquoi il faut créer plus de programmes-jouets

• Citation célèbre de Richard Feynman : « Ce que je ne peux pas créer, je ne le comprends pas » → l’expérience de fabriquer quelque chose soi-même mène à une compréhension profonde
• Contrairement au conseil classique de « ne pas réinventer la roue », le fait de fabriquer soi-même la roue enseigne bien plus que la lecture ou l’apprentissage théorique
• Récemment, l’IA et l’industrialisation du logiciel menacent le plaisir et le sens de l’artisanat dans le développement
• La création de logiciels-jouets permet de retrouver ce plaisir simple qui nous faisait tomber amoureux de l’informatique

Principes des programmes-jouets : Keep it simple

• Les logiciels-jouets suivent le principe du 80:20 : 80 % des fonctionnalités avec 20 % de l’effort
• L’objectif n’est pas le produit final, mais la simplicité et l’implémentation directe des principes essentiels
• Mise en garde contre l’over-engineering : l’accent est mis sur l’écriture du seul code réellement nécessaire
• Il est recommandé de laisser tous les chemins de code non encore implémentés, puis d’étendre l’implémentation à mesure que le besoin apparaît
• Même un système qui semble petit peut, dans la pratique, se révéler étonnamment facile à construire

Bénéfices annexes des logiciels-jouets

• Les connaissances acquises dans les projets-jouets aident souvent bien plus qu’on ne l’imagine, au travail, pour traquer des problèmes, corriger des bugs et éviter des erreurs
• Le fait de se confronter directement aux contraintes apporte des éclairages sur la nature même du logiciel et peut aussi conduire à des solutions innovantes

Exemples : liste de projets de logiciels-jouets

Cette liste rassemble, avec leur niveau de difficulté et leur durée estimée, différents types de projets-jouets implémentés directement au cours des 15 dernières années. Chaque projet inclut une brève description et des ressources complémentaires

• Moteur de regex (difficulté 4/10, 5 jours) : interprétation de regex de style POSIX et identification des chaînes correspondantes, pour comprendre en profondeur le fonctionnement interne des expressions régulières
• Noyau d’OS x86 (difficulté 7/10, 2 mois) : inclut une CLI, des pilotes simples, un gestionnaire mémoire, avec possibilité d’ajouter un système de fichiers en mémoire, des exécutables ELF, une GUI, l’isolation des processus, etc.
• Émulateur GameBoy/NES (difficulté 6/10, 3 semaines) : compréhension d’un jeu d’instructions simple et du matériel, implémentation du PPU, du PSG et de formats de cartouches particuliers
• Jeu GameBoy Advance (difficulté 3/10, 2 semaines) : petit jeu basé sur des sprites, communauté de développement GBA active, architecture système qu’on peut tout à fait maîtriser seul
• Moteur physique 2D (difficulté 5/10, 1 semaine) : mécanique newtonienne de base et gestion simple des collisions, extensible à des formes complexes, l’inertie, des algorithmes de résolution, les soft bodies ou des interactions composites
• Interpréteur dynamique (difficulté 4/10, 1 à 2 semaines) : interpréteur parcourant un arbre ; créer son propre langage procure un plaisir à la fois technique et créatif
• Compilateur de type C (difficulté 8/10, 3 mois) : système de types simple et environnement cible, conception d’une architecture prenant en charge diverses optimisations et plusieurs backends
• Éditeur de texte (difficulté 5/10, 2 à 4 semaines) : à partir d’entrées/sorties de fichiers simples, possibilité d’utiliser un toolkit UI (QT/GTK, etc.), préférence pour la console, avec fonctionnalités supplémentaires comme Unicode, coloration syntaxique, multi-buffer, LSP, etc.
• Runtime async (difficulté 6/10, 1 semaine) : dans le cas de Rust, gestion de tâches impl Future et implémentation de la concurrence, avec ajout du réveil I/O
• Hash Map (difficulté 4/10, 3 à 5 jours) : compréhension du fonctionnement interne, apprentissage du closed addressing et de l’open addressing, de la règle du robin hood, ainsi que des performances et des bons cas d’usage
• Rasteriser / Texture Mapper (difficulté 6/10, 2 semaines) : apprentissage de la structure du pipeline graphique 3D, des mathématiques vectorielles, du Z-buffer, avec approfondissement possible vers le texture mapping et les algorithmes de shading
• Rendu par Signed Distance Field (difficulté 5/10, 3 jours) : représentation mathématique de l’espace, visualisation simple, meilleure compréhension des shaders et des mathématiques vectorielles
• Moteur voxel (difficulté 5/10, 2 semaines) : plus facile à appréhender si l’on a une expérience en graphisme 3D ou en développement de jeux, avec défis supplémentaires possibles comme les textures, la génération procédurale ou le réseau
• Machine virtuelle threaded (difficulté 6/10, 1 semaine) : interpréteur rapide, implémentation d’un interpréteur optimisé sans génération de code spécifique à l’architecture, avec des performances pouvant rivaliser avec celles d’un compilateur
• Toolkit GUI (difficulté 6/10, 2 à 3 semaines) : après une première expérience de création d’outils UI de base, possibilité d’implémenter soi-même des fonctions avancées comme un moteur de layout, le text shaping ou l’accessibilité
• Simulateur de mécanique orbitale (difficulté 6/10, 1 semaine) : implémentation simple d’un modèle newtonien de gravitation, extensible aux interactions entre plusieurs corps célestes, aux algorithmes d’intégration, à la visualisation, voire à l’utilisation de données de la NASA
• Bitwise Challenge (difficulté 3/10, 2 à 3 jours) : jeu entièrement reproductible à partir d’un état 64 bits, excellent exercice de gestion créative de l’état, avec règles détaillées disponibles sur GitHub
• Framework ECS (difficulté 4/10, 1 à 2 semaines) : implémentation directe d’une architecture Entity-Component-System, intégration au système de types du langage, avec réglage possible des contraintes et des performances
• Émulateur CHIP-8 (difficulté 3/10, 3 à 6 jours) : machine virtuelle simple des années 1970, rapide à implémenter, permettant d’observer et d’exécuter de nombreux fan games
• Moteur d’échecs (difficulté 5/10, 2 à 5 jours) : on commence par les règles puis on progresse peu à peu ; perdre contre le moteur qu’on a soi-même écrit est une étape marquante dans la progression d’un développeur
• Shell POSIX (difficulté 4/10, 3 à 5 jours) : compréhension des principes et des limites d’un shell fondé sur POSIX, ainsi que de la profondeur de la compatibilité avec le langage shell réel et des nombreuses astuces qu’elle implique

Conseils sur l’usage d’outils comme les LLM

• Les outils avancés comme les LLM sont utiles, mais le véritable apprentissage devient plus profond quand on explore soi-même
• Plutôt que de regarder des solutions existantes, on peut tirer un sentiment d’accomplissement plus fort du processus d’exploration de l’inconnu et de la recherche de sa propre réponse
• Mener un projet-jouet sans LLM peut sembler difficile au début, faute d’habitude, mais avec le temps on ressent un plaisir technique propre et un fort sentiment d’accomplissement

• Se déplacer en voiture ne permet pas de ressentir le « runner’s high » d’un coureur → c’est dans l’expérience directe, et non dans le raccourci, que l’on trouve une joie profonde

[tolluset]

Je comprends bien l’idée qu’il faut essayer sans LLM. Quand il n’y a pas besoin de développer rapidement, j’ai l’impression que construire soi-même en comprenant chaque élément un à un est plus amusant et plus gratifiant.

[nezz1204]

Vous parliez donc d’un projet perso. En voyant seulement le titre, j’ai cru qu’il s’agissait de développer un logiciel pour des jouets. Haha.

[GN⁺]

Avis Hacker News

• Je me demande qui utilise les LLM comme moteur de recherche. Avant, je cherchais sur Google des choses comme « pros cons mysql mongodb », puis je lisais la documentation officielle, des forums, des blogs et Stack Overflow, ce qui prenait beaucoup de temps. Mais j’ai toujours apprécié le temps passé à apprendre en lisant. Maintenant, je donne au LLM des prompts plus précis du genre « avantages et inconvénients de mysql vs mongodb pour stocker des photos, avec des liens de référence ». Ça permet de cerner rapidement l’essentiel, et j’aime le fait d’avoir aussi les liens pour ne pas dépendre des hallucinations. Il m’arrive aussi de lui demander des choses plus concrètes, comme « conçois un data schema pour stocker des métadonnées de photos dans postgres, je veux séparer X dans une autre table », mais je ne le fais que quand je sais exactement à quoi le résultat doit ressembler. En gros, je l’utilise quand je veux éviter de perdre du temps à taper ou quand j’oublie momentanément un nom de type précis (int vs integer, etc.)

  • Quand on utilise un LLM comme moteur de réponses techniques, il donne souvent des informations qui ont l’air plausibles mais sont fausses sur des points importants. Si on les croit telles quelles et qu’on suit la réponse, on peut perdre inutilement des heures, voire des jours. Même en demandant des liens de référence, c’est du 50/50 entre des sources réellement pertinentes et du contenu sans rapport. En revanche, il y a une chose qu’il fait vraiment bien : la recherche inversée façon « tip-of-my-tongue ». Autrement dit, si on décrit un concept, il sait proposer les bons mots-clés à rechercher ; sur ce point, c’est assez constant et satisfaisant
  • D’ici peu, les entreprises paieront probablement beaucoup d’argent aux LLM pour que leurs produits apparaissent sous un jour plus favorable dans les comparatifs. Les LLM peuvent simplement changer le cadrage et l’accent mis sur certains éléments pour que le résultat paraisse « organique ». Il suffit de ne montrer que des informations vraies et sourcées, tout en jouant sur « l’accent contextuel »
  • J’utilise moi aussi les LLM pour chercher des informations. J’ai l’impression de revenir au début des années 2010, quand googler était incroyablement puissant. L’époque où on pouvait tout trouver. Bien sûr, ça n’a pas duré, et aujourd’hui googler est devenu une expérience de douleur et de frustration pure. J’ai beaucoup de griefs contre les changements apportés par Google et les marketeurs, mais j’ai l’impression que les LLM sont actuellement très efficaces pour faire remonter instantanément de l’information présente en ligne. Les liens de référence sont aussi, en général, plutôt exacts. Au final, les mêmes forces de transformation qu’avant finiront par agir, donc j’ai l’impression que c’est une brève fenêtre d’opportunité avant que cela disparaisse à nouveau
  • Je fais aussi partie de ceux qui utilisent les LLM comme moteur de recherche. Je n’utilise pas encore d’IDE IA. Lors d’un entretien technique en direct récemment, j’ai essayé de répondre en interrogeant le LLM que j’avais choisi comme je l’aurais fait avec Google, et l’intervieweur m’a dit que c’était la première fois qu’il voyait un candidat utiliser l’IA de cette manière. Je pensais que la plupart des développeurs utilisaient encore surtout l’IA pour chercher, avant de passer aux IDE IA. Est-ce que des cas comme les nôtres sont rares ?
  • J’utilise même les LLM comme moteur de recherche pour le développement : « analyse le dépôt que j’ai cloné dans /src/foo et explique-moi comment barFeature y est implémentée. Maintenant regarde le projet /src/baz et explique-moi pourquoi l’approche de foo s’applique difficilement à baz ». Je ne lui demande pas de faire quelque chose de nouveau ; je m’en sers pour traduire dans mes idées ce qui existe déjà dans le projet. Le développement vraiment nouveau et stimulant, j’ai envie de le coder moi-même

• L’une des meilleures décisions de ma carrière a été un projet personnel mené pendant six mois de pause entre deux emplois. J’avais à l’origine beaucoup de projets à lancer, mais comme je n’avais pas de contraintes, le périmètre ne cessait de gonfler et je finissais souvent par ne rien terminer. J’ai donc décidé de n’investir qu’une semaine par projet. Je ne faisais que ce qu’il était possible de faire en une semaine. Partir de zéro et construire en une semaine quelque chose d’utilisable dans un nouveau langage, un nouveau framework ou un domaine peu familier a énormément renforcé ma confiance. Ça m’a aussi rappelé pourquoi j’aimais programmer au départ. Si vous avez quelques mois de pause entre deux postes, au lieu de préparer des entretiens à la Silicon Valley, fabriquer simplement des toy projects peut vous surprendre par tout ce que vous savez déjà

  • Avec des outils de génération IA, ce genre de toy projects personnels devient une énorme aide. Je fais surtout du backend, mais je peux aussi faire du frontend. Simplement, le CSS me prenait tellement de temps qu’avant, je n’arrivais souvent pas à terminer mes projets personnels. Maintenant, il suffit de demander à l’IA « rends ça joli » et elle m’amène à 85 % du résultat ; il ne reste plus qu’à corriger quelques bugs ou à ajuster, ce qui permet d’aller vite jusqu’au bout. Là où le développement ressemblait autrefois à un bourbier, c’est aujourd’hui devenu tellement plus fluide que je fais des projets personnels bien plus souvent
  • Ces derniers temps, j’accumule tellement de frustration envers les bibliothèques que j’utilise que je finis par les corriger moi-même. Quand je tombe sur une documentation d’onboarding incomplète, un SDLC cassé ou de graves problèmes de performance, je peux passer la journée à réparer ça. Contrairement à un projet collaboratif où d’autres attendent après vous, les toy projects personnels rendent très facile le fait de partir dans des side quests. La collaboration met la pression parce que quelqu’un attend vraiment
  • Je me demande comment tu as pu t’arrêter six mois et retrouver ensuite un emploi. J’aimerais moi aussi prendre six mois, mais ça m’angoisse de me dire que je pourrais ne pas retrouver de travail et devoir m’arrêter encore plus longtemps
  • Quand j’étais plus jeune, je mettais en place des serveurs en classic ASP + SQL, je gérais HTML/CSS/JS et je déployais facilement. À l’époque, il suffisait d’envoyer les fichiers en FTP. Aujourd’hui, j’aimerais explorer des méthodes plus modernes, mais quand je fais des projets personnels, je me perds souvent à chaque fois dans les questions de déploiement et de processus de développement. Je suis curieux de savoir comment vous choisissez l’hébergement et la stratégie de déploiement pour vos toy projects
  • Moi aussi, l’IA accélère clairement ce type de projets personnels en générant le boilerplate ou du code d’automatisation de tests

• Développer des toy software, c’est comme entretenir des vélos, des voitures ou des bateaux. C’est plaisant. Mais réparer son vélo de trajet quotidien, c’est stressant. Créer du toy software, c’est amusant, mais dès que je veux vraiment l’utiliser un jour, je découvre tous les bugs, et je n’ai plus le temps de les corriger ; c’est tout le dilemme

  • Je préfère développer uniquement des logiciels destinés à mon propre usage. Avec les voitures aussi, ce qui me satisfait, c’est de les garder longtemps et à moindre coût
  • J’ai un temps administré mon propre serveur mail, mais ce n’est plus le cas. Ce n’est pas parce que je voulais vraiment le faire moi-même ; c’est juste le genre de chose que je préfère désormais laisser à des spécialistes
  • J’ai récemment créé ma propre application de facturation. C’était amusant d’ajouter les fonctionnalités une à une. J’y ai inclus toutes les fonctions pour lesquelles il aurait fallu payer un abonnement mensuel sur des services existants, mais au moment d’envoyer réellement une facture, je me suis rendu compte qu’il y avait encore trop de problèmes à régler dans mon appli — style, saisie d’adresse, etc. J’ai fini par sentir qu’il fallait trouver un équilibre entre le plaisir de faire du vélo et l’utilité d’un vélo de transport quotidien. Avec le temps, j’ai réalisé que le plaisir et l’utilité pouvaient peut-être se rapprocher progressivement
  • J’ai moi aussi énormément de choses que j’aimerais transformer en « logiciel terminé », mais je n’ai ni le temps ni l’énergie. Il y a aussi beaucoup de tâches ennuyeuses et répétitives. Cela dit, gérer et trier des « résultats IA », c’est aussi pas mal de travail. J’en suis encore au stade des premières expérimentations, donc je ne sais pas si j’aurai encore cet avis dans quelques mois
  • C’est pour ça que créer un site personnel est vraiment amusant. On peut vraiment l’utiliser comme son propre terrain de jeu

• Je suis surpris de voir autant d’avis négatifs sur les LLM. Les LLM vous servent l’information à la cuillère. Quand on démarre un nouveau projet, on ne commence évidemment pas en sachant tout. On fait de son mieux, on se plante, puis on étudie, on comprend pourquoi ça n’a pas marché, et on ajuste avec une nouvelle approche : c’est ça, le vrai apprentissage. Si on suit simplement un tutoriel parce qu’on sait déjà tout, on ne fait pas l’expérience concrète des limites ni des vrais avantages et inconvénients de chaque méthode. Par exemple, si on essaie de construire un parseur avec des expressions régulières, on découvre soi-même qu’elles ne gèrent pas les expressions récursives, et on apprend aussi au passage les structures plus complexes ou les problèmes de complexité temporelle. En implémentant soi-même un compilateur optimisant et en butant sur toutes sortes d’astuces d’optimisation, on finit par comprendre pourquoi les vrais compilateurs sont conçus ainsi. Il faut aussi écrire soi-même un moteur de layout pour ressentir à quel point même une notion comme width est pénible à traiter correctement. Il n’y a pas de meilleure expérience que celle de l’apprentissage par essais et erreurs. Même si les LLM évitent certaines erreurs, j’aimerais qu’on ne rate pas pour autant ces occasions d’apprentissage importantes

  • Beaucoup disent qu’on prendra du retard si on n’utilise pas les LLM, mais j’ai plutôt l’impression que les utiliser moins pourrait être un gros avantage à long terme

• Moi aussi, j’ai passé des années, les week-ends et les nuits, à faire d’innombrables projets bizarres pour apprendre l’infographie. Je n’ai pas gagné un centime avec ça, mais c’est ce qui m’a permis d’obtenir le job de mes rêves. Quelques liens vers des réalisations représentatives :

  • Tiny ray-tracer
  • 2D rigid-body simulator
  • Character animation system
  • Animation curve visualizer
  • Motion capture playback in the web Le véritable but de toutes ces montagnes de code, c’était toujours « acquérir des connaissances »

• J’ai l’impression qu’on a vraiment besoin de l’esprit de « plaisir de programmer » mis en avant par ce texte. À l’ère du coding par agents IA, c’est peut-être encore plus précieux. En revanche, j’ai l’impression que l’estimation de l’auteur sur le temps nécessaire pour ces toy projects est beaucoup trop courte. Je ne suis peut-être pas dans la moyenne, mais même en supposant qu’on n’y travaille que 2 ou 3 heures par jour, je pense qu’une grande partie de cette liste ne se termine pas en quelques jours. Rien que la phase de recherche avant de commencer prend déjà pas mal de temps. Par exemple, j’ai récemment remplacé mon blog Pelican par mon propre static site generator Odin ; même à raison de 2 à 3 heures par jour, ça m’a pris deux semaines. Et pourtant, c’était probablement plus simple que les autres projets de la liste

  • Ton projet est au-delà du simple « toy » project. Tu es toi-même le vrai client et tu t’attends à ce qu’il fonctionne correctement après déploiement. C’est cette attente qui marque la frontière entre un jouet et un vrai outil. On peut faire un traitement de texte en une heure : il traite peut-être juste une seule entrée à la fois, il est absurdement simple, il n’a même pas de bouton pour quitter. Mais pour un « toy » traitement de texte, ça suffit
  • Si on interprète une durée de « X jours » comme 24*X heures, cette liste devient plus plausible
  • L’un des avantages des toy projects, c’est justement l’absence de deadline. On peut donc avancer tranquillement, très lentement si on veut. Moi aussi, je peaufine encore depuis l’époque du Covid un langage Turing-complet basé sur PEG
  • Ce genre de compression du temps dépend énormément de jusqu’où on s’appuie sur des bibliothèques tierces, de ce qu’on choisit de résoudre soi-même, et de la concentration réelle sur le cœur du sujet. Si on regarde le GitHub de l’auteur (https://github.com/ssloy?tab=repositories), on peut apprendre beaucoup de choses sur la manière de garder l’échelle petite. Et puis l’auteur a déjà une compréhension très profonde du domaine, ce qui lui permet de coder de façon aussi « serrée ». Avec un sujet nouveau, ce serait difficile de procéder de cette manière

• Je suis d’accord avec le conseil « n’utilisez pas les LLM pour ce genre de projets », mais je pense qu’il ne faut pas le prendre de manière trop extrême. La question de savoir comment se faire aider par l’IA, et pourquoi cela semble différent du fait de demander de l’aide à une personne, est d’ailleurs intéressante. Si le billet disait en bas « si vous avez un ami très bon en programmation, ne lui demandez jamais d’aide », ce serait étrange. Un ami expert comprend le contexte et vous aide à résoudre le problème par vous-même. Presque personne n’a sans doute essayé de dire explicitement à l’IA : « je ne veux pas que tu résolves le problème à ma place ; guide-moi comme le ferait un ami expert ». Bien sûr, pour l’instant, elle peut en être incapable ou le faire imparfaitement, mais dans un ou deux ans, ce type de guidance deviendra peut-être tout à fait naturel. Donc, prendre l’habitude de préciser clairement quel type d’aide on veut me paraît une bonne chose. Il n’est pas nécessaire de partir du principe qu’un LLM ne fournira que des réponses fausses

  • J’ai clairement le sentiment que l’IA n’est pas encore un développeur expert
  • Utiliser un LLM comme un ami expert, c’est même l’usage que j’en fais le plus souvent. Pour obtenir quelque chose de fiable, il faut aussi formuler les prompts ou les questions d’une manière moins biaisée. J’ai l’impression que Claude ou ChatGPT ont récemment tendance à trop aller dans mon sens
  • (auteur) En réalité, je recommanderais vraiment aussi de « ne pas demander d’aide même à un ami expert ». Quand on est vraiment bloqué, il vaut mieux au pire lire un peu de littérature sur le sujet. Je crois très fortement que le fait d’essayer soi-même de multiples approches, de se cogner aux murs et de s’en sortir est un élément essentiel pour développer la créativité et les capacités de résolution de problèmes. Il faut absolument traverser une période de confusion. Cela dit, chacun doit décider pour soi
  • En pratique, je pose mes questions au LLM comme si je m’adressais à un « professeur ». Je ne lui demande pas de répondre comme un stagiaire

• Grâce au vibe coding basé sur Claude, j’ai enfin recommencé un side project amusant après très longtemps. Une fois les outils et le processus assimilés, j’ai rapidement construit en quelques semaines toute une série d’apps : un tableau de bord familial calendrier/météo, une appli de lecture Bluesky (qui masque les posts déjà vus), un tableau de bord PM d’entreprise gamifié, une extension Chrome qui masque des posts Reddit après un certain temps, ou encore une appli qui remplace un plugin WordPress plus maintenu. Au début, je laissais Claude faire beaucoup de choses, comme améliorer l’UI, mais maintenant j’ai appris à me satisfaire d’un niveau de finition à 90 % et à concentrer mes efforts sur les nouvelles fonctionnalités plutôt que sur le raffinement

  • Je suis parfois gêné quand Claude corrige un bug mais ne montre pas immédiatement le résultat. Il m’est déjà arrivé de devoir lui redemander jusqu’à six fois d’afficher la sortie mise à jour pour une seule correction. Je me demande si d’autres ont vécu la même chose

• Cette liste est vraiment impressionnante. Un bon nombre des projets que l’auteur juge faciles me sembleraient d’un niveau de difficulté bien plus élevé. Mais elle a clairement un effet motivant : elle me donne envie de relancer mes propres toy projects. En revanche, la conclusion sur l’apprentissage avec les LLM est plus nuancée. Tout dépend entièrement de la manière dont on les utilise. Par exemple, une demande du type « implémente-moi simplement ce problème » est catastrophique pour apprendre, alors que « explique-moi la structure d’ELF au niveau le plus abstrait, en te concentrant sur le “pourquoi” » est au contraire un formidable accélérateur d’apprentissage. Le fait de ne plus faire soi-même toute la recherche peut être un inconvénient, mais si l’on garde une vraie posture intellectuelle, le simple fait de pouvoir avoir à tout moment un échange socratique de questions-réponses constitue un énorme accélérateur d’apprentissage

  • (auteur) C’est exactement ce que j’appelais dans le texte « certains types d’apprentissage ». Par exemple, pour apprendre la structure d’un binaire ELF, on ne peut pas la découvrir uniquement par suppositions personnelles. Il faut connaître l’histoire ou le processus de décision, donc il faut utiliser des sources de référence, que ce soit des specs, de la documentation ou des LLM. Mais ce qui est fondamental, c’est le « constructive learning » qui consiste à fabriquer soi-même. C’est en créant son propre format binaire et en se débattant avec qu’on finit par comprendre les raisons d’être d’un format réel comme ELF, ses problèmes et tout l’espace de conception. Pour ce type d’apprentissage exploratoire, je recommande de ne pas se faire aider par les LLM. « Si on me donnait juste un ordinateur portable, un éditeur de texte et un compilateur, puis qu’on me laissait dix ans seul, jusqu’où pourrais-je aller ? À quel moment me faudrait-il chercher des informations concrètes pour ne plus être bloqué ? »

• Les projets présentés ici sont de très bonnes idées, mais aucun ne m’intéresse vraiment. Dans ces moments-là, je me demande si j’ai réellement aimé programmer un jour

  • J’ai l’impression d’être ton exact opposé. La plupart des projets de la liste m’intéressaient, et ce sont des sujets que beaucoup de gens aimeraient essayer ou ont déjà essayés. En fait, moi aussi je me posais cette question jusqu’à récemment, puis un bébé est né et j’ai pris un congé ; j’en ai profité pour commencer un projet de code « simple », juste pour le plaisir. J’ai décidé de supprimer toutes les dépendances et de tout construire moi-même depuis zéro, et c’est devenu bien plus complexe que prévu, mais c’est aussi ce qui faisait que j’attendais avec impatience ces quelques heures de code. Tout à coup, coder est redevenu extrêmement amusant. Peut-être que tu es simplement en burn-out