Avancer vite, puis abandonner

• En restaurant des fichiers d’un jeu Mac inachevé datant d’environ 1991, on voit se répéter une méthode de développement consistant à implémenter rapidement des idées, puis à les abandonner sans hésiter si elles manquaient de fun ou de chances d’aboutir
• La liste de l’époque comptait 27 titres, mais seuls 5 ont réellement été publiés ; les autres étaient plutôt des prototypes rapides réalisés sur environ 18 mois
• Grâce à un shell commun pour les jeux à sprites, le coût des nouvelles expérimentations était faible, et les fonctions de son, de meilleurs scores et de sauvegarde étaient repoussées jusqu’à ce que le potentiel soit confirmé
• Des expérimentations comme kite-fighting, K-10 ou Thief of Baghdad étaient poursuivies ou non selon le plaisir des contrôles, l’objectif du jeu, et la quantité d’art et d’implémentation supportable pour un développeur seul
• Les projets abandonnés n’étaient pas pour autant du gâchis : du code comme le Fisher–Yates shuffle, le changement de profondeur de couleur de l’écran, la détection de collisions ou des tables de correspondance trigonométriques a été réutilisé dans des projets ultérieurs

---

Restauration d’anciens projets de jeux Mac

• En restaurant depuis un vieux disque dur des fichiers de jeux écrits il y a environ 35 ans, les expérimentations presque jamais terminées se révèlent plus intéressantes que les titres sortis
• Les jeux shareware publiés à l’époque ont été regroupés sous forme d’images disque et mis en ligne dans Soft Dorothy Software — Early Shareware Projects
  • Ces images disque sont utilisables en les glissant-déposant dans des émulateurs Mac 68K ou PPC comme Basilisk II, Sheepshaver ou MiniVMac
• Les sources et outils de build liés à Glider 4.0, publié par Casady & Greene en 1991, se trouvent dans l’image disque Casady & Greene Projects
• AirBikes aurait été un jeu de course futuriste s’il avait été terminé, mais il est resté inachevé

Seulement 5 titres sortis sur 27

• Un document créé vers 1991 répertoriait le creator code, le nom et l’état de chaque jeu
  • Le creator code ressemblait à une sorte de bundle identifier très rudimentaire de l’époque Macintosh pré-OS X, et devait être unique pour chaque application
• La liste comptait 27 titres, dont 5 seulement ont été publiés
  • Les autres étaient pour la plupart des prototypes rapides
  • Ces projets ont été réalisés sur environ 18 mois
  • Au moment où la liste a été rédigée, il semble que 3 titres étaient en développement simultané
• Un utilitaire appelé UnMask a aussi été publié, mais comme il s’agissait d’un outil écrit en une dizaine de minutes, il peut être écarté de l’analyse

Une méthode de prototypage rapide

• De nombreuses expérimentations ont été créées en codant tous les jours jusque tard dans la nuit, et un shell commun pour jeux à sprites a réduit le coût de création de nouveaux prototypes
• Pour une nouvelle esquisse de jeu, le temps était surtout consacré à créer les sprites et l’art dans MacPaint ; un peu de code était nécessaire pour les modes de saisie propres au jeu, les mécaniques et la physique
• Les fonctions comme le son, les meilleurs scores ou les sauvegardes n’étaient pas développées dès le départ, mais repoussées pour n’être ajoutées plus tard qu’aux jeux qui valaient la peine d’être sauvés
• L’essentiel était de vérifier rapidement si l’idée était réellement amusante
  • Une idée qui semble amusante sur le papier peut différer du plaisir réel de jeu
  • En implémentant les contrôles et la physique en quelques jours, il était possible de savoir si cela valait la peine de continuer

Les critères pour vérifier rapidement le fun

• Un jeu de combat de cerfs-volants permettait d’implémenter et de tester en quelques jours le pilotage et la physique du vol
  • Si contrôler le cerf-volant était déjà trop difficile, peu de personnes risquaient d’apprécier le jeu
  • Si le simple fait de faire voler le cerf-volant était amusant, même sans élément de combat, il y avait du potentiel
• Dans le jeu d’arcade Joust, le simple fait de voler avec le bouton de battement d’ailes était déjà amusant avant même l’apparition des ennemis
  • Les moments où il fallait battre lentement des ailes comme ceux où l’on martelait frénétiquement le bouton pour monter rapidement contribuaient tous au ressenti de jeu
• Un jeu où un avion en papier utilise les bouches d’aération au sol pour gagner de la portance dans une maison en désordre avait aussi un certain intérêt avant même que l’on comprenne l’objectif : traverser les pièces et éviter des objets comme des toasts
• K-10 était un autre jeu de course nommé d’après la Kansas highway 10, mais il n’a jamais dépassé le stade de prototype

Décider d’abandonner ou de continuer

• Certains jeux avaient bien un début d’implémentation, mais la suite à leur donner n’était pas claire
  • La liste mentionnait froidement <no point> pour plusieurs jeux
• Le jeu de plateforme Thief of Baghdad était amusant dans sa partie où l’on courait et sautait sur un tapis volant, mais l’objectif suivant du jeu restait flou
• Dans les conditions d’un développement en solo, il était difficile de poursuivre un projet qui semblait prometteur mais aurait demandé plus d’un an pour être terminé
  • Un jeu d’aventure à sprites dans le style Dungeons and Dragons était séduisant, mais la charge de travail était importante : animations selon les armes du joueur, monstres, effets de sorts et système de combat
  • Une fois les animations de coups d’épée et de parade réalisées, il aurait encore fallu ajouter des variantes comme le fléau, l’arc ou la cape, ce qui augmentait la charge artistique

Les ressortir, et réutiliser le code

• Les jeux mis de côté n’étaient pas des projets totalement morts ; si les sources, ressources et fichiers de projet pouvaient être retrouvés, ils pouvaient être ressortis
• Thief of Baghdad a été relancé environ 18 mois plus tard en version couleur, a reçu le nom Scheherazade, et a commencé à gagner un semblant d’objectif
  • Mais même au deuxième essai, il n’a pas acquis assez de charme difficile à expliquer pour justifier sa poursuite, et a de nouveau été arrêté
• Le code des projets mis en pause pouvait être réutilisé dans des travaux ultérieurs
  • Fisher–Yates shuffle algorithm
  • Code pour changer la profondeur de couleur du moniteur sur les premiers Mac
  • Code de collision polygon-point
  • Table de correspondance de sinus pour une trigonométrie rapide
  • Routines de dot-product et cross-product
• Ce travail de prototypage n’était pas considéré comme du gâchis

Une méthode itérative poursuivie chez Apple

• À mesure que les années 1990 avançaient, l’époque des développeurs indie de jeux Mac semblait toucher à sa fin ; lorsqu’on lui a proposé d’aller en Californie pour travailler chez Apple, il a accepté
• Après son arrivée chez Apple, il comprenait qu’il ne pouvait pas travailler sur des projets non-Apple pendant son temps libre
  • Strictement parlant, coder hors travail nécessitait une autorisation écrite de son manager
  • Comme Apple n’était pas dans le jeu vidéo, il aurait peut-être pu obtenir cette autorisation, mais le risque de la demander et de se voir opposer un refus restait pesant
• Même sur des projets professionnels qui n’étaient pas des jeux, l’approche de prototypage rapide a continué
  • D’autres collègues itéraient sur la conception au tableau blanc et planifiaient soigneusement avant d’écrire du code
  • Lui préférait se lancer d’abord, compiler et itérer
• Il rassemblait rapidement du code pour trouver vite les goulets d’étranglement, puis, si nécessaire, recommençait presque le projet depuis le début
  • Même après avoir démarré puis redémarré un projet trois fois environ, il arrivait souvent à un état suffisamment bon à peu près au moment où les collègues qui avaient conçu avec prudence parvenaient à exécuter leur code
• La dernière révision du code était généralement une simplification, et le fait de traiter le code dès le départ comme quelque chose qui pouvait être largement modifié lui donnait une intuition sur la manière de l’organiser
• Il a aussi vécu une situation où il pouvait répondre à un collègue qui recommandait un Bloom Filter qu’il l’avait déjà écarté, car les données réelles étaient trop petites pour apporter un gain de performance notable et cela ne faisait qu’ajouter de la complexité à la base de code

Always Be Iterating

• Au moment de prendre sa retraite, il avait le sentiment d’avoir été un employé contributeur et un collègue chez Apple
• Contrairement à l’époque où il codait seul toute la nuit, les ingénieurs avec lesquels il a travaillé ont été la meilleure partie de son passage chez Apple
  • Parmi les personnes avec lesquelles il a travaillé, certaines étaient des programmeurs d’au moins un ordre de grandeur meilleurs que lui
• Il avait le sentiment d’être l’un des programmeurs les plus rapides, plutôt le genre de personne capable de produire deux versions d’un prototype pour une démo lors de la réunion de la semaine
• La phrase qu’il répétait à ses filles était A.B.I.
  • « Always »
  • « Be »
  • « Iterating »
  • autrement dit « Always Be Iterating »
• Les projets, sources et outils des jeux jamais sortis ont été organisés en images disque et publiés sur GitHub
  • Soft Dorothy Software: Unfinished Tales (Vol. 1)
  • Soft Dorothy Software: Unfinished Tales (Vol. 2)
• Un Volume 3 est également prévu, mais comme chaque projet doit être remis dans un état « publiable », aucune date de publication n’est promise

[GN⁺]

Avis sur Hacker News

• Depuis que j’ai commencé à programmer vers 1989, j’ai entre une bonne dizaine et peut-être une centaine de projets laissés à l’abandon, la plupart étant des jeux. La plupart étaient conçus pour Mac Plus ou Mac LC, et beaucoup avaient des mécaniques ou des styles graphiques similaires à ceux évoqués dans l’article.
  Les quelques projets que j’ai sortis ou auxquels j’ai participé me donnent l’impression d’être comme l’ombre de la personne que je suis. Mon CV et mon parcours aussi. Comme les empreintes d’un être complet qui vivait une vie rêvée qui n’a jamais pu se concrétiser, faute d’occasion d’accumuler des réussites au début. C’est pour cela que je pense que le revenu de base pourrait multiplier par 10 ou 100 le potentiel humain, nous faire passer d’une économie de services à une économie d’agentivité et d’accomplissement personnel, et permettre à chacun de créer un revenu résiduel. Et j’ai énormément joué à Pararena.

  • J’ai un avis différent, que je me suis forgé pendant la pandémie, quand une situation semblable à un revenu de base s’est installée autour de moi et de mes amis. Les personnes qui n’avaient plus besoin de travailler sont devenues dépressives assez vite par rapport à celles qui ont continué à travailler, et cela a changé ma vision du revenu de base.
    Peut-être que votre entourage était différent, ou que votre pays n’a pas adopté cette approche. Je me demande quelle est la différence entre travailler sur plusieurs jeux et se concentrer sur un seul jusqu’à le terminer. Avec un revenu de base, pourrait-on faire ce genre de choses au point de produire des projets achevés, et pas seulement brièvement, mais de façon durable ? À certaines étapes de la vie, comme quand on devient parent ou pendant l’enfance, un revenu de base peut avoir du sens, mais dans une période où l’on se cherche, je pense que les responsabilités aident.
  • Le revenu de base ne fonctionnera pas. Dans mon pays, il est presque déjà en place. On peut toucher 600 euros par mois et diverses aides sociales sans travailler, et le résultat, c’est le plus gros déficit public de l’UE, des taux d’imposition parmi les plus élevés au monde, une criminalité généralisée, la difficulté de gagner de l’argent en travaillant à cause de ces impôts, et un exode massif des personnes éduquées vers l’étranger.
  • Si même le salaire minimum n’a pas très bien marché, je ne vois pas quels indicateurs pourraient faire croire qu’un système similaire consistant à donner de l’argent à des personnes qui ne travaillent pas fonctionnerait.
    J’ai vraiment du mal à comprendre ce raisonnement. Un revenu de base magique deviendrait le salaire minimum des masses qui ne travaillent pas ; comment cela pourrait-il être durable ou bénéfique ?
  • Nous vivons des vies différentes. Moi, je n’ai participé qu’à des projets dont les produits auraient franchement dû être abandonnés. Ce n’étaient pas des jeux, mais c’est bien dans cet état qu’ils ont été lancés.
    En théorie, il aurait aussi été possible de les terminer correctement, mais si l’organisation avait tenté de le faire, elle aurait fait faillite ; ce n’était donc qu’une option théorique. Quand je vois l’état des logiciels que j’utilise au travail, et que je dois aussi utiliser à titre privé, j’ai l’impression que tout le monde autour de moi vit la même chose. Heureusement, les utilisateurs n’ont pas le choix : ils doivent acheter un truc médiocre, ou ne rien acheter du tout. Nous ne risquons rien à vendre des choses médiocres.
  • Les choses inachevées, on les appelle simplement de la recherche. J’ai plusieurs projets Unreal Engine 4/5 et je ne les terminerai jamais, mais du point de vue des tests de mécaniques de jeu, du rigging et de l’animation, du développement de shaders ou de la création d’assets 3D, c’était amusant.

• Beaucoup d’entreprises où j’ai travaillé fonctionnent comme ça. Les ingénieurs créent une nouvelle fonctionnalité brillante, elle est lancée, tout le monde est content. Quelques mois plus tard, les bugs se sont accumulés.
  Les personnes qui l’ont créée sont déjà passées dans une autre équipe. Le prétexte, c’est de « casser les silos », mais en réalité cela ressemble plutôt à « rendre tout le monde remplaçable ». Les ingénieurs qui héritent du projet doivent en assurer la maintenance et corriger les bugs jusqu’à ce qu’une autre équipe en hérite à son tour. C’est horrible.

  • C’est l’enfer que nous avons nous-mêmes créé en acceptant largement le produit minimum viable comme bonne méthode de développement produit. Nous jugeons la viabilité à la liste de fonctionnalités, pas au fait que cette fichue chose soit solide ou maintenable.
    En plus, « minimalement viable » n’est qu’à un pas de « non viable ». Chaque projet devient comme Icare, à tester jusqu’à quelle distance du soleil il peut voler avant que ses ailes ne fondent.
  • Je plaisante souvent en disant que toutes les offres d’emploi de startup après la Series A ressemblent à une demande de faire du Viscera Cleanup Detail[1] pour nettoyer derrière les « héros » de la phase pré-product-market fit.
    [1]: https://store.steampowered.com/app/246900/Viscera_Cleanup_De...
  • J’étais l’auteur initial d’une fonctionnalité qui définissait l’entreprise ; on m’a dit qu’il fallait « casser les silos », je m’en suis retiré, puis j’ai vu mon travail se dégrader pendant des années, donc je suis entièrement d’accord.
    Les personnes qui en ont hérité n’étaient pas qualifiées pour prendre des décisions, ma vision d’ensemble a été mise de côté, et voir l’incompétence avec laquelle cette fonctionnalité était gérée était insupportable. Aujourd’hui encore, chaque bug stupide m’agace. Surtout que j’avais prévenu alors qu’il y avait encore largement le temps d’ajuster le tir. Mais j’en ai tiré une leçon importante, et je peux dire avec certitude que la prochaine fois, même si je passe pour quelqu’un de têtu, je ne reculerai pas et je me battrai.
  • C’est tout à fait vrai, mais je ne pense pas que ce soit le point que l’article original cherche à défendre, ni son intention. L’article ressemble plutôt à une invitation à essayer plusieurs choses, à sentir ce qui est techniquement possible et ce qui semble intéressant pour les clients, puis à pousser dans cette direction.
    Cela convient bien aux développeurs indépendants, et s’applique aussi dans une certaine mesure aux grandes entreprises. Cette philosophie est utile pour identifier les fonctionnalités ou les produits qui valent vraiment qu’on y consacre du temps. En fait, la situation que vous décrivez peut même être vue comme le résultat direct du fait de ne pas avoir suivi l’approche proposée par l’article original.
  • Ce que vous décrivez ne semble pas avoir grand-chose à voir avec cet article.

• Ces derniers temps, je suis revenu au développement rétro. Je crée des logiciels pour Macintosh 68K, la plateforme sur laquelle j’ai appris à programmer
  J’ai fouillé dans beaucoup de vieux livres, de messages comp.sys.mac.programmer et de code source comme Soft Dorothy et GliderPro. Regarder du vieux code avec un regard neuf est une expérience étrange. On voit aussi pourquoi les anciens Mac plantaient autant, au-delà de la simple explication « il n’y avait pas de protection mémoire ». Comme l’auteur, j’aime aussi le pixel art 1 bit, et je tiens une liste de comptes Twitter qui en publient. Si quelqu’un manque, dites-le-moi : https://twitter.com/i/lists/1578111923324944397
  Ce qu’il y a de bien dans la programmation pour des systèmes contraints, c’est que cela limite les choix. C’est une bonne pause par rapport à l’expérience moderne où l’on peut tout faire en important simplement la bonne bibliothèque. J’imagine parfois un monde où la puissance de calcul se fige, et où les logiciels destinés à des systèmes bien compris ne font que s’améliorer. Les anciens systèmes comme le Mac 68K ont connu un rythme d’évolution matérielle si rapide qu’il en donnait presque le vertige. Quand un nouveau processeur comme le 68020 ou le 80386 sortait, on n’avait au mieux que quelques années pour créer quelque chose qui exploite vraiment son potentiel. Si l’on arrivait trop tard, il fallait déjà rivaliser avec de nouveaux logiciels conçus pour une nouvelle génération de matériel

  • Avec plus de 30 ans de recul, quand je revois mon code, j’ai envie de le refactorer et de simplifier les corvées courantes comme la réponse aux événements de fenêtre
    J’aimerais aussi créer des fonctions d’enrobage pour manipuler les Handle, etc. Cela dit, comme mentionné, c’est surprenant de voir à quel point la Toolbox était simple par rapport aux systèmes d’exploitation modernes. Refaire du développement rétro me paraît vraiment amusant
  • Je fais du pixel art 1 bit pour Playdate, qui est une plateforme contrainte. Pas aussi contrainte qu’un Macintosh Plus. Sur Twitter, je suis @gingerbeardman, et voici un exemple : https://blog.gingerbeardman.com/2024/07/14/shibuya-pixel-art...
  • Les images tramées des Mac 68k m’ont fait aimer le pixel art 1 bit. J’ai aussi tramé certaines des photos que j’utilise comme fonds d’écran

• Tout le blog est excellent. Il y a beaucoup de choses intéressantes à parcourir
  On peut abandonner quelque chose, apprendre même de projets abandonnés, et parfois en réutiliser des morceaux. Pour moi, le déclic a été de décider de réduire suffisamment la portée pour pouvoir terminer. Cela m’a aidé à développer l’art de finir, qui est une compétence à part entière et difficile à apprendre. Parce qu’elle ne se manifeste qu’au bout d’un processus trop long et trop dur, on y arrive rarement. Tous mes amis qui font des jeux vidéo commencent par écrire leur propre moteur, puis s’épuisent au moment de créer l’éditeur de niveaux. Ils apprennent beaucoup de choses sur la création d’outils, ce qui, ironiquement, ressemble à ce qu’ils savaient déjà faire, mais ils ne créent pas réellement de jeu. C’est comme apprendre la taille de pierre en construisant une cathédrale : on n’en verra pas la fin. Il faut commencer par quelque chose d’assez petit pour ne pas pouvoir échouer, puis passer progressivement à des projets plus grands

  • Le fait que « tous mes amis qui font des jeux vidéo commencent par écrire leur propre moteur », je l’ai aussi vu plusieurs fois. Même quand on décide d’utiliser des outils existants, on peut facilement tomber dans un puits de complexité sans fond
    Je travaille actuellement sur un projet Unity, et je me suis retrouvé bloqué en me demandant quelle était la meilleure façon de créer un système de placement de bâtiments façon RTS. Au lieu de foncer comme d’habitude, j’ai décidé de modifier le concept du jeu pour que le joueur n’ait tout simplement pas besoin de placer des bâtiments. En expérimentant, j’ai constaté que c’était en fait une meilleure expérience utilisateur pour ce que je voulais créer. Au début, je me suis dit « on ajoutera le système de bâtiments à la prochaine itération », mais désormais je ne pense probablement plus le faire
    Retirer des éléments est presque toujours préférable. Mener réellement à terme un petit point de départ, c’est comme du nitrométhane pour l’itération suivante. Il faut atteindre 100 % pour que la suite soit nettement meilleure. S’arrêter à 80 % laisse seulement l’impression de devoir repousser le rocher en haut de la colline
  • Je ne crois pas avoir jamais terminé un seul projet personnel. En tout cas, pour moi, c’est la compétence la plus difficile à développer
  • Me concentrer sur la réduction d’un projet personnel jusqu’à ce qu’il devienne réellement terminable pourrait être exactement ce dont j’ai besoin en ce moment
  • Récemment, je suis passé du développement front-end à l’accessibilité. Il y a quelques années, j’avais créé plusieurs sites statiques, templates et projets de design, mais je les avais finalement laissés de côté pour diverses raisons
    Après avoir commencé à travailler sur l’accessibilité, j’ai ressorti beaucoup d’entre eux pour les rendre accessibles. Certains utilisaient de très vieilles versions de Bootstrap, alors j’en ai aussi profité pour les mettre à niveau vers une version récente de Bootstrap. Rien qu’en rendant accessibles d’anciens designs, j’ai énormément appris. J’ai l’impression d’avoir acquis une bien meilleure perspective sur ce qu’il faut regarder lorsqu’on évalue des sites et des applications. Cela m’a aussi fait prendre conscience du manque d’accessibilité de ce que j’avais moi-même créé
  • La compétence qui consiste à terminer ce que l’on commence semble absente des discussions sur la productivité. Je me demande s’il existe des billets de blog ou des articles qui l’expliquent plus en détail

• Les jeux de John ont été une source d’inspiration pour moi quand j’apprenais à programmer sur Mac, enfant. J’ai beaucoup joué à Glider, et encore plus à Pararena. J’ai encore en tête cet échantillon sonore de démarrage résonnant
  J’ai probablement passé encore bien plus de temps à fouiller dans les resource forks de ces jeux avec ResEdit. Je n’ai pas terminé grand-chose, mais j’ai tout de même achevé quelques petits jeux shareware et les ai mis sur AOL. Quelques mois plus tard, j’ai été vraiment surpris de recevoir dans ma boîte aux lettres un chèque venu de la lointaine Californie
  Les débuts du Mac ont vraiment été une période particulière, avec le sentiment qu’un développeur seul pouvait, avec de la créativité et du temps, créer quelque chose et le diffuser dans le monde. Merci d’avoir écrit ce texte et de m’avoir replongé dans ces souvenirs ; j’espère que vous profitez bien de la retraite

  • Vous avez peut-être lu mes autres textes ou le README de mon dépôt d’images disque. Cette époque était particulière
    Était-elle particulière parce que, en tant que premiers utilisateurs et premiers développeurs d’ordinateurs, tout était nouveau pour nous ? Ou bien y avait-il quelque chose de différent dans l’air à ce moment-là ? Je suis heureux que vous ayez aimé les petits jeux que j’ai créés. Je me demande aussi si ce chèque venu de Californie a contribué à vous pousser vers la carrière qui est la vôtre aujourd’hui

• Si l’objectif de cet article est de normaliser le fait d’abandonner des projets, je ne suis pas sûr que ce soit une bonne idée. Même en mettant tout le reste de côté, cela peut représenter une énorme perte de temps, et dire « au moins, on a appris quelque chose » ne suffit pas à le justifier. Ne devrait-on pas aussi apprendre en allant jusqu’au bout ?

  • Dans un excellent épisode de Smarter Every Day, Destin travaille avec un atelier de verrerie pour enfermer dans un bloc de résine une goutte de Prince Rupert brisée.
    Comme personne ne l’avait jamais fait, ils trouvent la méthode au fur et à mesure et commettent pas mal d’erreurs en cours de route. L’un des points soulignés dans la vidéo, c’est que lorsque cela arrive, l’équipe ne s’arrête pas simplement pour réessayer la même chose. Elle continue jusqu’à tout gâcher complètement, et en profite pour expérimenter librement avec le matériau.
    Il explique longuement à quel point c’est formidable. Si l’on était sur la voie de fabriquer un produit fini et poli, on n’oserait pas tenter certaines choses ; là, on saisit une occasion incomparable d’en apprendre davantage sur le comportement des matériaux manipulés. Comme il est difficile d’abîmer encore plus quelque chose qui est déjà bon pour la poubelle, il est même discutable de dire qu’on prend encore un risque.
    Je pense qu’il a raison de dire qu’un état d’esprit qui privilégie l’apprentissage et l’expérimentation plutôt que la seule réussite est l’une des meilleures façons de devenir vraiment excellent dans ce que l’on fait.
  • Il y a aussi des choses qu’il a effectivement terminées. L’idée clé est d’éviter la paralysie de l’analyse et de « s’y mettre » au lieu de continuer à y penser indéfiniment. C’est un biais pour l’action et un refus des coûts irrécupérables.
  • C’est une mauvaise lecture de l’article. Il parle plutôt de découverte par prototypage itératif rapide, ce qui inclut aussi le fait de détecter tôt et vite les défauts rédhibitoires.
  • Je trouve le titre mauvais. La leçon serait plutôt : « Travaillez sur tout ce qui vous passe par la tête, mais ne publiez rien avant que ce soit prêt. Certains projets ne seront peut-être jamais prêts, et ce n’est pas grave. Dans 30 ans, vous pourrez les mettre sur GitHub par nostalgie. »
    ChatGPT résume cela par : « Construisez vite, ne lancez jamais. Jusqu’au moment où vous lancez. »
  • Je pense qu’il est sain que des projets meurent. Cela libère du temps pour démarrer d’autres projets, au lieu de rester enfermé dans un carcan.
    Parfois, on s’accroche à un projet qui ne mène nulle part, en pensant qu’avec assez d’efforts il finira par aboutir, alors qu’il n’est plus amusant et qu’on n’apprend plus rien. On se met la pression avec des « il faut que je le termine, il faut que je le termine », puis quand on se demande « pourquoi ? », c’est généralement par peur de ne pas finir, ou peut-être par peur de ne pas savoir distinguer un passage difficile d’un projet raté. Dans un cas comme dans l’autre, j’ai trop souvent ressenti un soulagement en acceptant l’échec. Cela devient une occasion de repartir.

• Certaines des œuvres en pixel art dans les captures d’écran sont vraiment superbes.

• Personnellement, j’ai beaucoup plus appris et gagné en publiant de petites choses, puis en itérant dessus ou en les abandonnant.

• J’aime cette approche et je la trouve intéressante, mais elle me paraît plus délicate au niveau organisationnel. Beaucoup de choses que l’on découvre sur les projets et les technologies concernent leur faisabilité à l’échelle où le projet réel fonctionne, et elles n’apparaissent pas forcément dans de petites expérimentations.
  Parfois, le problème n’est pas technique, mais plutôt du genre : « Peut-on faire en sorte que la plupart des développeurs ici comprennent comment travailler de cette façon ? » Cela ne veut pas dire qu’il ne faut pas davantage tenter ce genre de choses. Il y a des choses à apprendre en essayant de petits projets. Mais cela ne garantit pas que cela fonctionnera aussi à grande échelle.

• Mon problème, c’est simplement le temps. Quand je rentre du travail, la dernière chose dont j’ai envie, c’est de m’asseoir devant un ordinateur.
  Même mes deux jours de repos par semaine doivent être remplis de tâches ménagères, donc je n’ai toujours pas envie de rester devant un écran.

  • Je suis junior et je cherche actuellement un stage, puis mon premier emploi.
    J’envie les gens capables de faire comme vous. En ce moment, le secteur ressemble à une secte qui ne recherche que des personnes ayant fait de la tech et de la programmation toute leur vie. Ce n’est pas que je déteste les exigences en elles-mêmes ; j’ai une éthique professionnelle et je veux bien faire, mais les attentes semblent plus élevées que jamais.
    J’espère acquérir assez de stabilité professionnelle pour avoir des loisirs qui ne m’obligent pas à fixer un écran. J’aimerais bientôt essayer le travail du métal.