Réinventer la roue - Reinvent the Wheel
(endler.dev)- Le conseil « Ne réinventez pas la roue » a un effet négatif en freinant la créativité et la curiosité d’exploration
- Le processus de création d’une nouvelle roue, c’est-à-dire de réinvention d’outils ou de technologies existants, apporte une compréhension profonde et de véritables apprentissages
- Même des composants fondamentaux simples ou familiers en apparence comportent en réalité de la complexité et de nombreux compromis
- En essayant d’inventer sa propre roue, on renforce ses capacités en matière de progression, résolution de problèmes et expérimentation
- L’accent est mis sur la nécessité de choisir avec équilibre, selon l’objectif, entre l’utilisation de résultats existants et la réinvention
Reinvent the Wheel
- L’expression « Ne réinventez pas la roue » part d’une bonne intention, mais vient de deux types de personnes
- celles qui ont essayé de fabriquer une roue elles-mêmes et en ont éprouvé la difficulté
- celles qui ne l’ont jamais tenté et suivent aveuglément un conseil existant
- Quand ce conseil se répète, il crée une atmosphère qui étouffe la curiosité et l’esprit d’exploration
- Si tout le monde l’avait suivi, beaucoup de commodités et de progrès modernes n’auraient pas vu le jour
- En réalité, la roue a été réinventée de nombreuses fois depuis son invention initiale et n’a cessé d’évoluer
Remarque : ici, la « roue » peut être remplacée par n’importe quel outil, protocole, service, technologie ou autre création
Inventer soi-même la roue, c’est apprendre
« Ce que je ne peux pas créer, je ne peux pas dire que je l’ai compris. »
— Richard Feynman
- Pour comprendre vraiment en profondeur quelque chose, il faut passer par l’expérience d’en implémenter soi-même une petite version
- Même si le résultat n’est pas parfait, et même s’il n’est jamais utilisé, le simple processus d’implémentation est essentiel
- De nombreux concepts de l’informatique — protocoles, chiffrement, serveurs web, etc. — peuvent sembler difficiles, mais en réalité tout le monde peut essayer
- Davantage de personnes devraient avoir l’occasion de comprendre la structure et la nature des technologies existantes en les construisant elles-mêmes
Tout est un processus d’exploration sans fin (Rabbit Hole)
- Les composants de base que nous tenons pour acquis — par exemple les chaînes de caractères ou les chemins de fichiers — sont en réalité très complexes
- Tenter d’implémenter sa propre bibliothèque de chaînes ou de chemins est une grande source d’apprentissage
- Ce processus mène à plusieurs constats
- même dans les choses ordinaires, il existe une complexité presque infinie
- créer quelque chose d’utile pour les autres est une occasion d’apprendre l’humilité
- toute abstraction a été créée par des humains, n’est pas parfaite, et d’autres compromis sont toujours possibles
- En cours d’implémentation, on se retrouve confronté à d’innombrables choix et problèmes liés à la correction, la simplicité, les performances, l’évolutivité et la portabilité
- La solution que l’on construit soi-même peut exceller dans certains domaines, sans convenir à tous les utilisateurs ni à toutes les situations
- Les solutions existantes ont elles aussi des limites et peuvent ne pas correspondre à mon problème
- L’expérience consistant à creuser un problème jusqu’au bout fait partie du processus de progression en tant qu’ingénieur
- Si l’on ne fait que passer sans cesse d’un projet à l’autre, on n’en retire pas d’apprentissage significatif
Pourquoi il faut réinventer la roue
- Pour fabriquer une roue meilleure que l’existante (la définition de « meilleure » peut varier)
- Dans un objectif d’apprentissage : comprendre comment une roue est fabriquée
- Dans un but pédagogique : enseigner à d’autres le principe de la roue
- Explorer le processus d’invention de la roue permet d’obtenir de nouvelles prises de conscience
- Développer la capacité de réparer ou améliorer soi-même quand elle casse
- Acquérir les différents outils et techniques nécessaires à la fabrication d’une roue
- Comprendre le rôle de la roue comme élément d’un système complexe (par exemple une voiture)
- Tenter de créer une roue très particulière répondant à un besoin spécifique (par exemple pour un fauteuil roulant, un skateboard ou un tour de potier)
- La roue que l’on a fabriquée peut finalement être mieux utilisée pour un tout autre usage que son objectif initial
- Dans le monde, les idées nouvelles qui sortent des cadres établis peuvent jouer un rôle important
Reuse vs Reinvent
- Il ne faut pas ignorer le travail des autres ; il faut l’étudier et l’utiliser de manière appropriée
- Il faut veiller à ne pas rejeter l’existant pour reconstruire à neuf par simple méfiance ou ignorance
- Cependant, sans implémenter ou expérimenter soi-même, il est difficile d’acquérir une compréhension fondamentale et de progresser dans le domaine concerné
- En ingénierie logicielle, les petites expérimentations et les prototypes sont faciles et rapides à réaliser, ce qui les rend efficaces pour résoudre des problèmes personnels
- Il est recommandé de commencer petit, implémenter simplement et itérer
- Donc, voici mon dernier conseil
- si vous voulez de l’insight, osez réinventer vous-même
- si vous voulez de l’impact, réutilisez des solutions déjà éprouvées
"Reinvent for insight. Reuse for impact."
« Réinventez pour la compréhension. Réutilisez pour l’impact. »
8 commentaires
Quand j’ai essayé de rendre une roue carrée ronde, je me suis souvenu de ce que disait le patron : il ne faut pas réinventer la roue. Les esprits hantés par ce mantra sont encore nombreux autour de nous.
« Réparer l’étable après avoir perdu la vache » ne veut pas dire qu’il ne faut pas se préparer à l’avenir,
et, de la même façon, « ne réinventez pas la roue » ne veut pas dire qu’il ne faut pas investir du temps pour acquérir des insights.
Si l’on coupe le contexte dans lequel ce genre de phrase a été prononcé, on en déforme le sens initial.
C’est une expérience récente, mais j’ai récemment créé ma propre roue très spéciale.
Construire une application Nuxt de 1000 pages prenait 7 minutes,
mais en renonçant à quelques automatisations et en la réécrivant, j’ai réussi à ramener le build à 20 secondes.
Il est difficile de décider jusqu’où réinventer, et jusqu’où s’appuyer sur des dépendances externes.
Dans tous les cas, choisir une dépendance pour gagner du temps alors qu’on pourrait la développer soi-même, et se retrouver lié à une dépendance sans laquelle on ne peut même pas construire le service, ce sont deux choses complètement différentes.
Ce ne sera pas possible pour tout le code (comme le système d’exploitation), mais faire l’effort d’aller autant que possible dans le premier sens aidera à mieux comprendre le système.
Les proverbes portent un sens, mais il y a de plus en plus de gens qui les interprètent uniquement mot à mot
Si ce genre d’argument devient à la mode, la salle de réunion redevient vite un joyeux chaos comme si de rien n’était
Les accros à la paperasse s’excitent, et on répète encore chaque année les mêmes échecs
Avis Hacker News
Il m’est arrivé de réinventer la roue dans un domaine précis. Ce n’était pas mon intention au départ, mais je pensais que la technologie existante était fondamentalement mauvaise. J’ai abordé un problème généralement jugé impossible avec une stratégie de diviser pour régner. J’ai eu de la chance, et j’ai été assez obstiné pour finir par réussir. Ma roue s’est révélée largement supérieure dans ce domaine. En expérimentant, j’ai découvert qu’on pouvait faire très facilement des choses qu’on croyait auparavant impossibles. Avec le temps, d’autres personnes du secteur ont commencé à utiliser ma roue. Au début, tout le monde est perplexe, mais une fois qu’on l’a apprivoisée, on ne revient plus en arrière. Je reçois du monde entier des rapports de bugs et des demandes de fonctionnalités pour des cas d’usage et des workflows improbables. J’ai eu des discussions techniques approfondies avec des gens brillants que je n’aurais jamais rencontrés autrement. J’ai vu d’autres accomplir avec ma roue des choses que personne n’avait imaginées. J’ai fait de nouvelles découvertes qui m’empêchent de dormir la nuit. Et c’est aussi amusant de voir mes collègues avoir le cerveau qui se fige quand on leur explique ce que fait ma roue. Il ne faut pas avoir peur de réinventer la roue. Personne ne sait sur quel chemin fou elle finira par rouler
Je pense qu’il manque une raison vraiment importante, au-delà du simple fait d’améliorer une roue existante. C’est qu’on peut fabriquer une roue parfaitement adaptée à soi, puis continuer à l’utiliser telle quelle. Je vois souvent des gens qui, au nom du “ne réinventez pas la même roue”, essaient de forcer une roue de voiture sur un vélo. Quand on construit soi-même chaque partie d’un système pour qu’elles s’emboîtent bien, on peut y gagner bien plus qu’on ne le pense
Une raison majeure de réinventer la roue, c’est d’éviter la complexité ajoutée inutilement par des dépendances sans intérêt
Je suis totalement d’accord. Si les bibliothèques populaires résolvent des problèmes dans toutes sortes de contextes, elles finissent souvent par embarquer énormément de code inutile. L’important, c’est que si je peux implémenter rapidement la fonctionnalité dont j’ai besoin, la faire moi-même est meilleur pour l’ergonomie et minimise les dépendances. En revanche, je déconseille absolument d’écrire soi-même une bibliothèque de cryptographie
C’est la principale raison pour laquelle je réinvente la roue. Les dépendances traînent avec elles tout un tas de fonctionnalités dont je ne veux pas. Moi, j’ai juste besoin de quelque chose qui me permette d’aller au supermarché du coin. Et personnellement, je ne fais pas confiance à du code opaque. Même si j’utilise une dépendance, elle doit être d’un niveau que je pourrais reproduire moi-même en y consacrant une journée, et que je peux auditer. Je n’utilise pas de binaires dont je ne peux pas voir le code source, sauf si je les ai achetés. Si c’est gratuit, alors le code source doit être public
J’ai créé moi-même une bibliothèque de task runner fondée sur un DAG (graphe orienté acyclique). Les tâches peuvent appartenir à des files. Je voulais pouvoir exécuter une démo dans un navigateur web, donc j’ai implémenté un backend IndexedDB, puis un backend SQLite pour une application Electron, et un backend Postgres pour un environnement serveur multi-utilisateur. J’ai aussi ajouté un limiteur de débit. En plus de ça, j’ai dû réinventer plusieurs autres roues autour du traitement de graphes ou des tâches. Si on veut tout faire sans la moindre dépendance, il y a vraiment énormément à faire. Cela dit, j’ai une branche séparée qui utilise TypeBox pour définir et valider les schémas d’entrée/sortie des tâches. Au final, il est possible qu’une autre dépendance finisse par entrer dans le cœur du système
Une autre raison, c’est que cela permet de s’entraîner à inventer ou à faire de la recherche sur du neuf. On peut très bien s’exercer avec des problèmes déjà résolus
Parfois, on réinvente la roue pour éviter une complexité inutile, comme des abstractions ou une modularisation superflues
C’était un bon essai, qui donne matière à réflexion. J’ai eu une expérience similaire : j’ai construit de zéro une bibliothèque de machine learning de style PyTorch (ml-by-hand) en n’utilisant que Python et NumPy. J’ai commencé par un petit moteur d’autograd, puis j’ai implémenté progressivement les couches, les optimiseurs, les dataloaders, etc. J’avais simplement envie d’apprendre les principes fondamentaux. Avec cette bibliothèque faite maison, j’ai réussi à reproduire aussi bien un réseau de neurones convolutionnel classique (cnn example) qu’un GPT-2 simple (gpt2 example). Sans les abstractions de PyTorch ou TensorFlow, j’ai beaucoup mieux compris comment fonctionne le machine learning en interne. En quelque sorte, j’ai même fini par construire moi-même une voiture avec la roue que j’avais réinventée
Pour compléter l’idée selon laquelle les personnes qui disent surtout “ne réinventez pas la roue” se répartiraient en deux catégories, je pense qu’il en existe en réalité une troisième, bien plus courante : celles qui connaissent vraiment les difficultés de la réinvention de la roue, qui sont passées par là, et qui jugent malgré tout que cela ne vaut absolument pas la peine de le faire soi-même, même d’un point de vue pédagogique
Réinventer la roue est la meilleure façon d’apprendre. Mais je pense que cela n’est vrai que dans un contexte d’apprentissage. Moi aussi, j’aime creuser les sujets en profondeur, mais au travail, il y a souvent des échéances et d’autres contraintes qui empêchent d’explorer librement. Si la roue qu’on fabrique est destinée à être utilisée réellement en production, elle doit selon moi être nettement meilleure que l’existante
Au travail, 99 % des gens qui réinventent la roue ne comprennent généralement même pas vraiment comment la roue existante est conçue ni pourquoi elle repose sur de tels compromis
Faire soi-même n’est pas forcément la meilleure manière d’apprendre. Cela demande beaucoup de temps et coûte cher. Avec une documentation bien structurée et un environnement d’expérimentation, on peut apprendre suffisamment. La clarté de la transmission du savoir est en soi un autre problème à résoudre. Il n’est pas nécessaire de tout reconstruire depuis le sol
Je suis en train de mener une expérience qui consiste à réimplémenter à l’échelle mondiale des systèmes gouvernementaux. Ce n’est pas lié à de vrais gouvernements. Par exemple, il y a ua.gov-ai.co, ua.ai-gov.co, ng.gov-ai.co, ng.ai-gov.co, etc. Pour l’instant, ce sont CBER et DDP qui ont le plus progressé. J’en suis actuellement à 422 agences. J’aimerais terminer d’ici Juneteenth. Le fait de reconstruire les fondations de cette manière m’aide à mieux comprendre les principes de base. Je sais bien qu’il n’en sortira sans doute rien de concret, mais c’est utile pour reformuler ma pensée chaque fois que l’essence du sujet change. Je trouve qu’expérimenter en réinventant la roue a toujours du sens
Si vous travaillez dans une startup, je pense qu’il faut autant que possible ignorer ce conseil. (Sauf si la roue à réinventer touche à la performance centrale de votre service.) Sinon, on risque surtout de gaspiller des ressources limitées et de voir l’entreprise échouer avant même d’avoir vraiment commencé
Malgré tout, dans une startup, je pense qu’il est important d’être entouré de personnes qui ont déjà fabriqué elles-mêmes des roues, autrement dit qui savent réellement en construire. Cela peut venir de l’open source ou de projets personnels
Ce conseil semble viser non pas le cadre professionnel, mais des expériences personnelles de réinvention de la roue à des fins d’apprentissage
Cela me rappelle une phrase d’un ami : « Si l’on réinvente la roue, ce n’est pas parce qu’il faut plus de roues, mais parce qu’il faut plus d’inventeurs. » J’ai souvent trouvé du réconfort, pour l’esprit comme pour le cœur, dans le fait de fabriquer moi-même les choses pour apprendre de nouveaux concepts. En découvrant la citation de Feynman, « Ce que je ne peux pas créer, je ne le comprends pas », cette expérience et cette conviction se sont encore renforcées. Chaque fois que je réinvente une roue, mon intuition sur le concept de départ devient plus solide, et j’apprends aussi des choses entièrement nouvelles que j’ignorais jusque-là
Je pense que cette aversion excessive pour la duplication est un problème de notre époque. Tout le monde devient pareil, mange la même chose, travaille dans des métiers similaires et agit selon des besoins comparables. Si on pousse à l’extrême des messages comme “n’interdisez pas de réinventer la roue”, on risque de finir en quelqu’un qui ne sait rien faire, uniquement dédié à satisfaire les besoins spécialisés de quelques riches. Une vie où l’on n’apprend plus ni à cuisiner, ni à cultiver, ni même à aimer
Une entreprise est-elle un endroit où l’on vient pour apprendre ? Ou un lieu où l’on recrée de la valeur à partir de la roue inventée par d’autres ?
Créer n’est qu’un début, et quand on exploite un service pendant une dizaine d’années, toutes sortes de problèmes finissent par surgir en cours de route ; pour tenir le coup à ce moment-là, il faut des bases solides... il faut apprendre.