Écrire davantage de logiciels « inutiles »
(ntietz.com)- Les logiciels inutiles sont une forme de jeu qui permet de retrouver le plaisir de l’informatique en se libérant de la pression du résultat pratique, et Hurl lui aussi était au départ une expérience née d’une « blague »
- Les techniciens passent facilement de longues périodes dans des environnements où ils doivent produire des résultats utiles, ce qui peut affaiblir l’étincelle de plaisir qui les a poussés à commencer à programmer
- Dans les projets ludiques, on choisit soi-même ses tests, son issue tracker et ses critères d’achèvement, et l’on peut s’arrêter à tout moment dès qu’on a suffisamment appris ou que le plaisir disparaît
- Un moteur d’échecs, un magasin clé-valeur implémentant une partie de l’API Redis, un utilitaire Wake-on-LAN, une visualisation d’échecs et une base de données d’échecs étaient des expériences pour apprendre les GUI, les systèmes, le réseau et l’intérieur des bases de données
- Traiter l’ordinateur avec moins de sérieux et essayer de créer des choses « qui semblent inutiles » est une manière réaliste d’allier apprentissage et plaisir
La liberté qu’offre « l’inutilité »
- On lui a demandé à propos de Hurl : « pourquoi l’avoir créé ? », et la réponse courte est : pour une blague
- La réponse plus longue est que les logiciels inutiles permettent de retrouver le plaisir et l’exploration en informatique
- Les techniciens sont généralement liés à la création de choses utiles
- Les ingénieurs logiciels écrivent du code qui résout de vrais problèmes
- Les chercheurs en informatique étudient des problèmes pour produire des résultats nouveaux et concrets
- Les rédacteurs techniques travaillent sur des technologies et des documents bien réels
- Beaucoup de personnes qui ont commencé à programmer y trouvaient, d’une manière ou d’une autre, du plaisir, et cette sensation a peut-être joué un rôle dans leur choix de carrière
- Quand on doit faire des choses utiles toute la journée, il est facile de voir son intérêt s’émousser
- Ce qu’il faut faire s’accompagne d’obligations et de pression
- Toutes les activités finissent reliées au travail lui-même
- On perd alors facilement un élément essentiel de jeu
- Les logiciels inutiles sont une façon d’échapper à ces obligations
- On peut décider soi-même de ce qu’on veut retirer du projet
- On peut s’arrêter à tout moment
- Si l’on n’a pas envie d’écrire des tests, on peut les omettre
- Si l’on n’a pas envie d’utiliser un issue tracker, on peut s’en passer
- Si l’on a appris ce qu’on voulait apprendre et que le plaisir a disparu, on peut mettre fin au projet
Des projets créés pour le jeu
- Le moteur d’échecs affreux avec son UI était plein de bugs, mais il a permis de mieux comprendre la programmation GUI, la programmation de jeux et le fonctionnement des moteurs d’échecs
- Le magasin clé-valeur a servi à apprendre la programmation système et à écrire du code plus efficace en implémentant une partie de l’API Redis
- L’utilitaire Wake-on-LAN était un projet destiné à comprendre le fonctionnement du WOL et à se former à la programmation réseau en Rust
- La visualisation de parties d’échecs a permis d’expérimenter la création d’art avec du code et la visualisation d’un jeu apprécié
- La base de données d’échecs a permis d’apprendre beaucoup de choses sur les bitmaps et les structures internes des bases de données
- Un outil fondé sur un LLM qui « mansplain » ce que font les commandes a aussi été créé
- Une implémentation côté serveur du protocole POP3 est restée inachevée, mais elle a apporté le plaisir d’apprendre le protocole et d’imaginer à quoi pourrait ressembler une application fondée sur POP3
- En suivant “Crafting Interpreters” en Rust, beaucoup de choses ont été apprises sur les interpréteurs et les compilateurs, et l’objectif n’était pas de terminer, mais d’y prendre plaisir
- “Mazes for Programmers” a été réalisé à moitié en Rust avant de se transformer en travail, puis d’être abandonné, sans envie d’aller plus loin
- De petits scripts ont aussi été écrits pour jouer avec des idées et des concepts, et expérimenter
- Hurl lui aussi est une forme de jeu : même sans être utile, on peut apprendre quelque chose et prendre plaisir au fait de créer
1 commentaires
Avis sur Hacker News
J’aime créer des logiciels inutiles. Rien que cette année, j’ai fait l’uncolouring book sur https://lines.potato.horse, MeatGPT sur https://meat-gpt.sonnet.io, Medieval Content Farm sur https://tidings.potato.horse, You deserve butter sur https://butter.sonnet.io, Mrr sur https://mrr.sonnet.io et le Mrr physiquement exact sur https://mrrr.sonnet.io
Certains sont en réalité plus proches d’articles de blog très travaillés, et ils sont surconçus parce qu’il m’est plus facile de m’exprimer en jouant avec du code que de résoudre de vrais problèmes. Une liste plus longue se trouve sur https://sonnet.io./projects
Mon enfant de 8 ans fait du Scratch tous les jours et je l’aide souvent quand il a des questions ; c’était vraiment amusant de faire un projet absurde, juste pour le plaisir, avec même une animation inutile. Grâce à ça, à la maison, « Hurry to love! Hurry to love! » est devenu une expression à la mode
En fait, j’en avais oublié pas mal
Tout à fait d’accord. Je suis allé récemment dans une école de clowns, et j’ai réalisé à quel point j’étais obsédé par l’idée de faire les projets « correctement » ou « bien »
La vie se vit, et quand on essaie de faire du logiciel de manière trop « correcte », on finit par en essorer tout le plaisir. Alors ces derniers temps, j’essaie d’écrire du code de façon plus joyeuse ; du coup, j’en écris beaucoup plus et ça coule beaucoup plus facilement. Récemment, pour tester des idées d’évolution de schéma, j’ai créé moi-même une bibliothèque de sérialisation binaire façon protobuf, et maintenant je travaille sur une base de données local-first fondée sur des CRDT. Hier, j’ai réussi ma première synchronisation de données, et j’étais vraiment surexcité. Pendant des années, j’ai écrit beaucoup de code pour résoudre des Serious Problems, et beaucoup de code impulsif aussi, mais ironiquement, le code dont je suis le plus fier est celui que j’ai écrit pour m’amuser. Les projets amusants, on y revient sans cesse pour les maintenir et les améliorer ; les projets sérieux, eux, dépérissent souvent une fois que je m’en vais
Dans les jeux, au lieu de se laisser porter et de faire confiance au processus, les gens se mettent à lire des guides pour créer le personnage le plus puissant, maximiser ses stats et viser le 100 %. Au final, le plaisir de l’exploration et des rencontres fortuites, qui rendait le jeu agréable, disparaît, et on passe son temps à maximiser des statistiques comme si l’on lançait des dés au hasard. C’est pareil pour d’autres activités : pendant qu’on essaie de maximiser quelque chose, que ce soit la richesse ou la qualité du code, l’émerveillement et le « j’essaie juste pour voir » disparaissent
https://www.asc.ohio-state.edu/kilcup.1/262/feynman.html
Puis on est tombés dans l’optimisation, et soudain c’est devenu un jeu où il n’y avait plus qu’une seule bonne réponse ; en une nuit, tout le plaisir s’est évaporé. On apprend souvent davantage en construisant quelque chose de mauvais par orgueil et par caprice. L’idée « à quel point ça peut être difficile ? » m’a plusieurs fois entraîné dans des profondeurs ingérables, mais en m’en sortant, j’ai toujours énormément appris et trouvé du plaisir
Dans n’importe quel métier artisanal (craft), il y a quelque chose de contre-intuitif. Si on en fait simplement davantage, en général, on finit par s’améliorer. Il faut écrire de mauvaises nouvelles, façonner des poteries moches, peindre des paysages de travers
Il y a sans doute l’effet de l’entraînement, mais il y a aussi une forte tendance à abandonner nos idées si l’on ne voit pas déjà parfaitement dans notre tête le produit fini que l’on peut espérer. Surtout pour les personnes analytiques, cela ressemble à une décision intelligente pour éviter de perdre du temps, mais c’est aussi un moyen sûr de ne rien créer du tout. Parmi les projets logiciels « inutiles », beaucoup sont restés inutiles, mais certains ont révélé une utilité plus grande au fil de leur création. Au bout du compte, on retombe sur un cliché du genre « 100 % des tirs qu’on ne tente pas sont ratés », mais vous voyez l’idée
Il ne s’agit pas seulement d’écrire des logiciels « inutiles » : c’est aussi un argument pour éviter les prétendues bonnes pratiques dans les petits projets
J’ai créé un générateur de site statique pour un catalogue d’articles ; le catalogue est simple et ne change pas souvent. Après m’être demandé quelle base de données utiliser, j’ai finalement décidé de tout mettre dans un tableau statique au sein de la base de code. Cela fait une dépendance de moins à prendre en compte, et c’est parfaitement adapté à mon besoin
Je ne sais pas si cela a réellement été changé ainsi, mais depuis, quand quelqu’un dit « il faut une base de données », c’est toujours la première question que je pose
Comme je charge de toute façon toutes les données en mémoire pour exécuter des algorithmes de graphe, j’ai réalisé que stocker des données en lecture seule dans une base de données n’avait presque aucun intérêt. Je n’ai absolument pas l’intention d’implémenter Bellman-Ford en SQL
J’ai appris ça en codant avec un ami que je pensais être un mauvais développeur
On s’entendait bien, donc on a fait beaucoup de projets amusants ensemble, mais il donnait vraiment l’impression de ne pas savoir ce qu’il faisait. Du copier-coller partout, pas d’architecture, pas de conception, des noms mal choisis, et la moitié du temps il ne semblait même pas certain de ce que faisait réellement le code. Mais ça marchait. Au final, j’ai compris qu’il avait accompli plus de choses que moi. Il ne s’accrochait pas aux détails, et il travaillait beaucoup plus. Il n’écrivait pas de tests unitaires, mais il jouait avec le résultat comme un enfant et le testait manuellement en continu. J’ai fini par adopter cette idée. Comme je ne trouvais pas de logiciel de contacts qui fasse ce que je voulais, j’ai voulu en créer un moi-même, mais au lieu d’essayer de faire une UI soignée, j’ai utilisé django-admin et j’en suis resté là. J’utilise cet horrible assemblage de formulaires depuis 10 ans, et il fait le travail. À l’époque où il n’existait pas de CLI pour TOTP, j’en ai fait une en Python et j’ai dumpé les seeds en clair dans du TOML. Il m’a fallu 5 ans pour ajouter le chiffrement, parce que créer un lien symbolique vers le fichier depuis un conteneur Veracrypt suffisait et demandait peu de travail. Il y a deux mois, je voulais un minuteur dont le budget de temps se remplit quand je fais du sport et se consomme quand je joue aux jeux vidéo, alors je l’ai fabriqué (https://substackcdn.com/image/fetch/w_1456,c_limit,f_webp,q_...). J’ai pris un tas de Tailwind recraché par ChatGPT, je l’ai piloté avec HTMX, et c’était suffisant. Je l’ai montré à des amis : 4 m’ont demandé un compte, et l’un d’eux a demandé un essai pour des médecins dans le cadre d’un programme d’addiction. Il n’y avait même pas de formulaire d’inscription, donc j’ai tout codé en dur. J’aimerais dire à mon moi plus jeune d’arrêter d’être obsédé par l’idée de faire les choses correctement ou de ne s’attaquer qu’aux problèmes importants. De toute façon, je n’ai jamais atteint la « bonne » manière de faire de toute ma vie
Depuis que j’ai commencé à garder le nom donné par l’IDE jusqu’à ce que le projet prouve qu’il est intéressant, mon taux de réussite semble avoir augmenté. Cela paraît lié au même principe de fond
C’est particulièrement étrange quand on nettoie le code de quelqu’un d’autre. On peste en se demandant « mais à quoi pensait-il ? », tout en sachant que cette personne a au moins lancé quelque chose
Mais il gagnait 100 dollars de l’heure dans un pays à bas salaires. Il achetait des domaines et du contenu, refaisait le logiciel, faisait des choses comme de l’optimisation pour les moteurs de recherche, puis revendait le tout au bout de 3 mois pour 10 fois le prix d’achat. Environ 7 000 dollars de bénéfice pour 3 mois de travail, ce n’est pas mauvais, et il est probable que ce n’était même pas son activité à plein temps
Mais ma conclusion a été la suivante. Premièrement, ils échouent aussi souvent qu’ils réussissent, il est impossible de prédire de quel côté ça tombera, et corriger après coup étant plus difficile que ne pas faire l’erreur dès le départ, cela ressemble à un pari à espérance négative. Deuxièmement, personnellement, je déteste travailler de cette façon. Troisièmement, je n’ai donc pas envie de consacrer du temps à des tâches où cette approche pourrait vaguement convenir. Cette expérience m’a poussé à chercher des projets plus profonds et plus vastes, plutôt qu’une succession de petites choses insignifiantes. En revanche, j’accepte maintenant beaucoup plus facilement que d’autres personnes puissent avoir des préférences différentes des miennes. Je pense davantage à la méthode qui me convient qu’à la bonne manière de créer du logiciel
Mais ça marche. C’est pénible, mais productif, et j’apprends beaucoup en cours de route. Je sais comment nettoyer, polir, rendre le tout maintenable et extensible plus tard ; je le ferai une fois que j’aurai quelque chose qui fonctionne vraiment. Je soutiens donc pleinement cette approche, surtout quand on essaie quelque chose de nouveau, parce qu’elle s’est déjà révélée assez productive par le passé
Apple avait autrefois rejeté mon app au motif qu’elle était inutile. L’équipe de validation des apps m’avait appelé directement pour me dire que cette app était inutile et ne serait pas approuvée sur le Mac App Store.
Environ 12 ans plus tard, cette petite app inutile, KeyboardCleanTool, était utilisée par des milliers de personnes. C’est une toute petite app gratuite qui bloque toutes les entrées du clavier et de la Touch Bar, et les gens l’ont utilisée de façons que je n’aurais jamais imaginées. Par exemple pour laisser un bébé taper à volonté sur le clavier, ou permettre à un chat de dormir sur l’ordinateur portable. Ce qui est utile est vraiment subjectif.
Après encore une dizaine de recherches, je suis tombé sur un article consacré aux bonnes méthodes pour nettoyer un clavier qui recommandait cette app parce qu’elle permettait de verrouiller le clavier, et c’est seulement là que j’ai compris. Je l’ai finalement téléchargée, et pour une app « inutile », elle s’est révélée plutôt pratique.
Quand j’étais enfant, ma mère avait accidentellement allumé notre Mac IIsi en faisant le ménage, et j’avais réussi à m’en servir comme prétexte pour la convaincre qu’il nous fallait l’économiseur d’écran After Dark. Peu après, des grille-pain volants apparaissaient à l’écran. Ça me rend nostalgique.
Pour voir la poussière susceptible de rayer pendant le nettoyage, l’écran du MacBook et le moniteur devaient être complètement noirs, et le trackpad devait aussi être désactivé. Pour désactiver le mode nettoyage, il fallait une combinaison de touches difficile à déclencher par accident mais facile à retenir ; j’ai donc choisi d’appuyer au moins 8 fois de suite sur la touche Command. Les pratiques de validation d’Apple sont toujours agaçantes. Je ne comprends pas pourquoi ils veulent décider à la place des utilisateurs de ce qui est utile. Sans parler des apps frauduleuses qui passent la validation et survivent des mois sur l’App Store.
J’aime utiliser des logiciels expressifs et ludiques. C’est pour apprendre et explorer, c’est ce qui m’a attiré vers la programmation et ce qui m’y retient encore.
Malheureusement, la nécessité s’en mêle. Sous la menace de la faim, il faut être productif. Je tiens aux personnes avec qui je produis, et je me sens coupable quand je ne produis pas. Cela finit même par aspirer la motivation de mon temps personnel. C’est étonnant de voir combien de personnes disposent de la stabilité et de la liberté nécessaires pour s’exprimer. J’envie les gens qui peuvent aller au Recurse Center, ceux qui ont d’innombrables billets de blog remplis de projets personnels et de récits d’aventure, mais j’en suis aussi heureux pour eux. La plupart ont probablement travaillé dur pour se mettre en position de construire cette vie. Moi aussi, j’aimerais faire ça. Mais pour y parvenir, il semble qu’il faille brûler encore plus de sa vie sur l’autel de la productivité. Si l’on sacrifie assez d’années, peut-être que la chance finira par vous accorder le droit de profiter de la vie. C’est drôle. Et alors, on appréciera encore davantage les logiciels inutiles.
Avant, je pensais que créer des logiciels utiles était la marque d’un développeur logiciel compétent, et je ne passais pas de temps sur des choses qui n’étaient pas manifestement utiles d’une manière facile à expliquer.
C’est une excellente façon de transformer le logiciel en corvée. Maintenant, je suis à l’aise avec le fait de créer des choses inutiles, et c’est amusant. Je refais des idées qui existent déjà d’une nouvelle manière, sans me soucier de savoir si quelqu’un l’a déjà fait. Si c’est juste pour le plaisir, on peut faire la même chose que reprendre la chanson de quelqu’un d’autre. On apprend, on s’amuse, et cela a de la valeur en soi. Parfois, on trouve même des façons d’améliorer les choses. Je l’ai appris en commençant à écrire du firmware. La pression d’être toujours utile était trop forte, et il a fallu que je mette mon ego de côté. J’ai découvert qu’écrire du code bancal pour faire des trucs idiots était extrêmement amusant, et c’est devenu une excellente façon d’apprendre et d’expérimenter des idées dans un contexte à faible pression. En plus, les choses inutiles peuvent devenir étonnamment utiles. Toutes les choses inutiles que j’ai créées ces dernières années ont débouché sur du code, des idées ou des connaissances utiles auxquels je ne m’attendais pas.
Il y a longtemps, j’animais un groupe appelé Houston Recreational Computer Programming Group. C’était une rencontre presque entièrement consacrée à la présentation de projets logiciels inutiles et amusants, et c’était très plaisant.
Depuis, j’ai déménagé, et je ne sais pas si la ville où je vis maintenant est assez grande pour créer un tel groupe, ni si j’aurais l’énergie de l’animer à nouveau. Ce que j’aimais personnellement, c’est qu’une fois par mois, je devais préparer un petit projet à montrer au cas où personne n’apporterait rien. En deux ans environ, cela n’est arrivé que quelques fois, mais l’un d’eux[1] est plutôt bien sorti et j’en suis fier. Il n’est d’ailleurs pas complètement inutile. [1] https://github.com/smcameron/gaseous-giganticus
Je viens tout juste de terminer un logiciel inutile il y a quelques minutes, donc cet article tombe vraiment à pic.
CFR Brackets : https://susam.net/cfr.html
Démo : https://susam.net/cfr.html#3
Source : https://github.com/susam/cfr
C’est un tout petit langage de dessin qui ne prend en charge que 5 commandes : C (changer de couleur), F (avancer), R (tourner), [ (début de bloc) et ] (répéter le bloc). Les commandes sont légèrement inspirées du langage de programmation Logo, et le minimalisme de P′′. Contrairement à ces deux-là, toutefois, il n’est pas Turing-complet. Il n’a aucun usage pratique prévu ; je l’ai créé pour m’amuser. Je compte encore jouer avec pour dessiner des formes intéressantes tout en gardant le code d’entrée aussi petit que possible. « Je pense qu’il est extrêmement important de préserver le plaisir du calcul dans l’informatique. » — Alan J. Perlis