Das Rad neu erfinden - Reinvent the Wheel
(endler.dev)- „Erfinde das Rad nicht neu“ ist ein gut gemeinter Ratschlag, der jedoch Kreativität und Entdeckergeist dämpfen kann
- Beim Erfinden eines neuen Rads, also beim Neuschaffen bestehender Werkzeuge oder Technologien, gewinnt man tiefes Verständnis und lernt viel
- Selbst einfache oder vertraut wirkende Grundbausteine enthalten in Wirklichkeit Komplexität und vielfältige Trade-offs
- Wer sein eigenes Rad erfindet, stärkt seine Fähigkeiten in Wachstum, Problemlösung und Experimentieren
- Es wird betont, dass man je nach Ziel bewusst zwischen Wiederverwendung bestehender Ergebnisse und Neuerfindung abwägen sollte
Reinvent the Wheel
- Der Satz „Erfinde das Rad nicht neu“ ist gut gemeint, stammt aber im Wesentlichen von zwei Arten von Menschen
- Menschen, die selbst einmal ein Rad gebaut und die Schwierigkeit dabei erlebt haben
- Menschen, die es nie versucht haben und nur blind einem bekannten Rat folgen
- Wenn dieser Ratschlag ständig wiederholt wird, entsteht ein Klima, das Neugier und Forschergeist abschwächt
- Würden sich alle daran halten, gäbe es viele moderne Annehmlichkeiten und Fortschritte heute nicht
- Tatsächlich wurde das Rad seit seiner ersten Erfindung immer wieder neu erfunden und weiterentwickelt
Hinweis: Mit „Rad“ kann hier jedes Werkzeug, Protokoll, jeder Dienst, jede Technologie oder jede andere Schöpfung gemeint sein
Das Rad selbst zu erfinden ist Lernen
„Was ich nicht bauen kann, habe ich nicht wirklich verstanden.“
— Richard Feynman
- Um etwas wirklich tief zu verstehen, braucht es die Erfahrung, wenigstens eine kleine Version selbst zu implementieren
- Auch wenn das Ergebnis nicht perfekt ist oder am Ende gar nicht genutzt wird, ist der Prozess des Bauens selbst wichtig
- Viele Konzepte der Informatik — Protokolle, Kryptografie, Webserver usw. — wirken schwierig, sind aber Dinge, die grundsätzlich jeder ausprobieren kann
- Wenn mehr Menschen Dinge selbst bauen, entstehen mehr Gelegenheiten, Struktur und Wesen bestehender Technologien zu verstehen
Alles ist ein endloser Rabbit Hole
- Selbst grundlegende Bausteine, die wir für selbstverständlich halten — etwa Strings oder Dateipfade — sind in Wirklichkeit hochkomplex
- Der Versuch, eine eigene String- oder Path-Bibliothek zu implementieren, kann ein großer Lernanlass sein
- Dabei erkennt man unter anderem Folgendes
- Auch alltägliche Dinge enthalten nahezu unendliche Komplexität
- Etwas zu bauen, das für andere nützlich ist, ist eine Gelegenheit, Demut zu lernen
- Jede Abstraktion wurde von Menschen geschaffen, ist nicht perfekt, und andere eigene Trade-offs sind ebenfalls möglich
- Während der Implementierung steht man vor zahllosen Entscheidungen und Problemen rund um Korrektheit, Einfachheit, Performance, Skalierbarkeit und Portabilität
- Die eigene Lösung kann in manchen Bereichen hervorragend sein, aber nicht für alle Nutzer oder Situationen passen
- Auch bestehende Lösungen haben Grenzen und passen womöglich nicht zu meinem Problem
- Sich in ein Problem bis zum Ende hineinzudenken, ist Teil des Wachsens als Engineer
- Wer nur ständig zwischen Projekten hin- und herspringt, gewinnt kein wirklich bedeutsames Lernen
Warum man das Rad neu erfinden sollte
- Man will ein besseres Rad bauen als das bestehende (wobei „besser“ vieles bedeuten kann)
- Man will lernen, wie ein Rad gebaut wird
- Ein pädagogisches Ziel: anderen das Prinzip des Rads beibringen
- Beim Erforschen des Erfindungsprozesses des Rads gewinnt man neue Einsichten
- Man entwickelt die Fähigkeit, es bei einem Defekt selbst zu reparieren oder zu verbessern
- Man eignet sich die verschiedenen Werkzeuge und Techniken an, die zum Bau eines Rads nötig sind
- Man versteht die Rolle des Rads als Teil eines komplexen Systems (z. B. eines Autos)
- Man versucht, ein sehr spezielles Rad für bestimmte Bedürfnisse zu bauen (z. B. für Rollstühle, Skateboards oder Töpferscheiben)
- Es kann sein, dass das eigene Rad sich für einen ganz anderen Zweck als den ursprünglich gedachten sogar besser eignet
- In der Welt können ungewöhnliche, unkonventionelle neue Ideen eine wichtige Rolle spielen
Reuse vs Reinvent
- Man sollte die Ergebnisse anderer nicht ignorieren, sondern ihre Arbeit studieren und sinnvoll nutzen
- Man sollte aufpassen, Bestehendes nicht einfach aus Misstrauen oder Unwissen zu verwerfen und neu zu bauen
- Ohne eigenes Implementieren oder Experimentieren ist es jedoch schwer, Kernverständnis und Weiterentwicklung in einem Bereich zu erreichen
- In der Softwareentwicklung sind kleine Experimente und Prototypen leicht und schnell umzusetzen und daher wirksam für die Lösung persönlicher Probleme
- Empfohlen wird, klein anzufangen, einfach zu implementieren und iterativ vorzugehen
- Deshalb lautet mein abschließender Rat
- Wer Einsicht (insight) will, sollte selbst neu erfinden
- Wer Wirkung (impact) will, sollte bewährte Lösungen wiederverwenden
„Reinvent for insight. Reuse for impact.“
„Neu erfinden für Einsicht. Wiederverwenden für Wirkung.“
8 Kommentare
Als ich versuchte, eckige Räder rund zu machen, musste ich an die Worte meines Chefs denken, man solle das Rad nicht neu erfinden. Diese "Erfinde-das-Rad-nicht-neu"-Gespenster gibt es in unserem Umfeld immer noch viele.
So wie „den Stall reparieren, nachdem die Kuh weggelaufen ist“ nicht bedeutet, dass man sich nicht auf die Zukunft vorbereiten soll,
bedeutet „das Rad nicht neu erfinden“ meiner Ansicht nach auch nicht, dass man keine Zeit investieren soll, um Einsichten zu gewinnen.
Wenn man bei solchen Aussagen den Kontext abschneidet, wird ihre eigentliche Bedeutung verzerrt.
Das ist eine aktuelle Erfahrung: Ich habe mir kürzlich mein ganz eigenes, sehr spezielles Rad gebaut.
Es dauerte 7 Minuten, eine App mit 1000 Seiten in Nuxt zu bauen,
aber nachdem ich auf einige Automatisierungen verzichtet und alles neu aufgebaut hatte, habe ich einen Build in 20 Sekunden geschafft.
Es ist schwierig zu entscheiden, was man wie weit selbst neu entwickelt und ab welchem Punkt man sich auf externe Abhängigkeiten stützt.
In jedem Fall ist es eine völlig andere Sache, eine Abhängigkeit zu wählen, um Zeit zu sparen, obwohl man es selbst bauen könnte, als an eine Abhängigkeit gebunden zu sein, weil man ohne sie den Service gar nicht entwickeln kann.
Das mag nicht für jeden Code möglich sein (etwa bei Betriebssystemen), aber es hilft dabei, das System zu verstehen, wenn man sich bemüht, so weit wie möglich in Richtung Ersteres zu gehen.
Sprichwörter tragen eine Bedeutung in sich, aber immer mehr Leute interpretieren sie nur noch wortwörtlich.
Wenn sich solche Behauptungen wieder als Trend durchsetzen, verwandelt sich der Besprechungsraum ganz selbstverständlich erneut ins Chaos.
Die Paperwork-Leute drehen dann völlig auf und dieselben Fehlversuche werden jedes Jahr aufs Neue wiederholt.
Hacker-News-Kommentare
Ich habe in einem bestimmten Bereich einmal mein eigenes Rad neu erfunden. Das war anfangs nicht mein Ziel, sondern geschah, weil ich die bestehende Technik für falsch hielt. Ich bin ein Problem, das normalerweise als unlösbar gilt, mit einem Divide-and-Conquer-Ansatz angegangen. Ich hatte Glück und war stur, und am Ende hat es funktioniert. Mein Rad zeigte in diesem Bereich eine überwältigend bessere Leistung. Bei Experimenten stellte sich heraus, dass Dinge, die zuvor als unmöglich galten, plötzlich sehr einfach wurden. Mit der Zeit begannen auch andere in diesem Feld, mein Rad zu benutzen. Zuerst sind alle verwirrt, aber sobald sie es einmal gelernt haben, wollen sie nie wieder zurück. Ich bekomme aus der ganzen Welt Bug-Reports und Feature-Requests zu seltsamen Use Cases und Workflows. Ich führe tiefe technische Gespräche mit klugen Menschen, die ich sonst nie getroffen hätte. Ich sehe, wie andere mit meinem Rad Dinge erreichen, die sich vorher niemand vorstellen konnte. Ich mache neue Entdeckungen, die mich nachts wachhalten. Und es macht auch Spaß zu sehen, wie meinen Kollegen das Gehirn einfriert, wenn man ihnen erklärt, was mein Rad kann. Man muss keine Angst davor haben, das Rad neu zu erfinden. Niemand weiß, auf welchen verrückten Weg es rollen wird.
Ich finde, es fehlt noch ein wirklich wichtiger Grund, der über die bloße Verbesserung eines bestehenden Rads hinausgeht: Man kann ein Rad bauen, das perfekt zu den eigenen Bedürfnissen passt, und es dann genau so weiterverwenden. Ich sehe oft Leute, die mit dem Spruch „Erfinde nicht dasselbe Rad neu“ versuchen, ein Autoreifen gewaltsam auf ein Fahrrad zu montieren. Wenn man alle Teile seines Systems selbst so baut, dass sie gut zusammenpassen, kann das mehr Vorteile bringen, als man denkt.
Ein wichtiger Grund, das Rad neu zu erfinden, ist auch, unnötige zusätzliche Komplexität durch nutzlose Abhängigkeiten zu vermeiden.
Dem stimme ich vollkommen zu. Bekannte Bibliotheken lösen Probleme in vielen unterschiedlichen Situationen, enthalten dadurch aber oft auch eine Menge unnötigen Code. Entscheidend ist: Wenn ich die benötigte Funktion in kurzer Zeit selbst bauen kann, ist Selbstbauen für die Nutzbarkeit oft besser und minimiert die Abhängigkeiten. Nur bei Kryptografie-Bibliotheken würde ich dringend davon abraten, sie selbst zu schreiben.
Das ist der Hauptgrund, warum ich das Rad neu erfinde. Mit Abhängigkeiten kommen viele unerwünschte Funktionen mit. Ich brauche nur genug, um mal kurz zum Laden um die Ecke zu fahren. Und persönlich vertraue ich keinem intransparenten Code. Selbst wenn ich eine Abhängigkeit nutze, sollte sie auf einem Niveau sein, das ich selbst an einem Tag nachbauen und auch reviewen könnte. Ausführbare Dateien, deren Quellcode ich nicht einsehen kann, benutze ich nur, wenn ich dafür bezahlt habe. Wenn etwas kostenlos ist, muss der Source Code offenliegen.
Ich habe selbst eine DAG-basierte Task-Runner-Bibliothek geschrieben. Tasks können zu Queues gehören. Weil ich Demos im Webbrowser laufen lassen wollte, habe ich ein IndexedDB-Backend implementiert, für eine Electron-App ein SQLite-Backend und für Multi-User-Server-Umgebungen ein Postgres-Backend. Dazu kam noch ein Limiter für Rate Limiting. Außerdem musste ich noch diverse andere Räder neu erfinden, etwa für Graph-Verarbeitung oder Task-Verarbeitung. Wenn man wirklich komplett ohne Abhängigkeiten bauen will, gibt es enorm viel zu tun. Ich habe aber einen separaten Branch, in dem ich die Input-/Output-Schemas der Tasks mit TypeBox definiere und validiere. Am Ende könnte also doch noch eine weitere Kernabhängigkeit dazukommen.
Ein weiterer Grund ist, dass man die Fähigkeit, Neues zu erfinden oder zu erforschen, durch Übung trainieren kann. Dafür reichen auch Probleme, die eigentlich schon gelöst sind.
Manchmal erfindet man das Rad neu, um Komplexität wie unnötige Abstraktion oder Modularisierung zu vermeiden.
Das war ein lesenswerter Essay, über den man gut nachdenken kann. Ich habe etwas Ähnliches gemacht und mit nichts weiter als Python und NumPy eine PyTorch-artige Machine-Learning-Bibliothek (ml-by-hand) von Grund auf gebaut. Angefangen habe ich mit einer kleinen Autograd-Engine und dann Schritt für Schritt Layer, Optimizer, DataLoader und mehr selbst implementiert. Ich habe das rein aus dem Wunsch heraus begonnen, die Grundprinzipien zu verstehen. Mit dieser selbstgebauten Bibliothek habe ich dann alles Mögliche nachgebaut, von klassischen Convolutional Neural Networks (cnn example) bis hin zu einem einfachen GPT-2 (gpt2 example). Ohne die Abstraktionen von PyTorch oder TensorFlow habe ich viel besser verstanden, wie Machine Learning intern funktioniert. Mit meinem neu erfundenen Rad habe ich also noch einmal selbst ein ganzes Auto gebaut.
Ergänzend zu der Aussage, dass es hauptsächlich zwei Arten von Menschen gibt, die sagen „Erfinde das Rad nicht neu“, glaube ich, dass es in Wahrheit noch eine dritte, viel häufigere Art gibt: Menschen, die die Mühen der Neuerfindung aus eigener Erfahrung kennen und deshalb zu dem Schluss kommen, dass es sich schlicht überhaupt nicht lohnt, den Prozess noch einmal selbst durchzumachen — auch nicht aus didaktischen Gründen.
Das Rad neu zu erfinden ist die beste Art zu lernen. Aber ich denke, das gilt nur im Lernkontext. Ich grabe mich selbst gern tief in Dinge ein, aber im Unternehmen gibt es Deadlines und andere Zwänge, die freie Exploration oft unmöglich machen. Wenn das gebaute Rad tatsächlich produktiv eingesetzt werden soll, muss es meiner Meinung nach den bestehenden Lösungen wirklich überlegen sein.
99 % der Leute, die bei der Arbeit das Rad neu erfinden, verstehen meist nicht einmal richtig, wie das bestehende Rad gebaut wurde oder warum es genau diese Kompromisse hat.
Selbstbauen ist nicht unbedingt die beste Lernmethode. Es kostet viel Zeit und Geld. Mit guter Dokumentation und einer brauchbaren Experimentierumgebung kann man genug lernen. Die Klarheit, mit der Wissen vermittelt wird, ist eine eigene Aufgabe. Man muss nicht zwangsläufig alles noch einmal komplett von unten aufbauen.
Ich experimentiere gerade damit, Regierungssysteme global neu zu implementieren. Nicht die echte Regierung. Zum Beispiel ua.gov-ai.co, ua.ai-gov.co, ng.gov-ai.co, ng.ai-gov.co und so weiter. Bisher sind CBER und DDP am weitesten fortgeschritten. Aktuell bin ich bei 422 Behörden. Ich würde das gern bis Juneteenth abschließen. Durch dieses Neuerfinden der Grundlagen verstehe ich die fundamentalen Prinzipien besser. Ich weiß, dass am Ende wahrscheinlich nichts Praktisches dabei herauskommt, aber es hilft mir dabei, meine Gedanken jedes Mal neu zu ordnen, wenn sich das Wesentliche verändert. Ich finde, Experimente zum Neuerfinden des Rads sind immer sinnvoll.
Wenn man in einem Startup arbeitet, sollte man diesen Rat meiner Meinung nach möglichst ignorieren. (Es sei denn, das neu erfundene Rad ist die Kernleistung meines Produkts.) Sonst verschwendet man nur die knappen Ressourcen und läuft Gefahr, dass das Unternehmen endet, bevor es überhaupt richtig begonnen hat.
Trotzdem halte ich es für wichtig, dass es in Startups Menschen gibt, die schon einmal selbst ein Rad gebaut haben — also Leute, die wirklich wissen, wie man eines baut. Das sollte es zumindest in Form von Open-Source-Arbeit oder privaten Projekten geben.
Ich glaube, dieser Rat ist nicht beruflich gemeint, sondern eher für persönliche Lernexperimente mit dem Neuerfinden des Rads.
Ich muss an einen klugen Satz eines Freundes denken: „Wir erfinden das Rad nicht neu, weil wir mehr Räder brauchen, sondern weil wir mehr Erfinder brauchen.“ Ich habe oft erlebt, dass mir das eigene Bauen neuer Konzepte geistig und emotional ein Gefühl von Stabilität gibt. Als ich Feynmans Satz „Was ich nicht erschaffen kann, habe ich nicht verstanden“ kennengelernt habe, wurde diese Erfahrung und Überzeugung für mich noch stärker. Jedes Mal, wenn ich das Rad neu erfinde, wird meine Intuition für das ursprüngliche Konzept stärker, und ich lerne auch Dinge, von denen ich vorher überhaupt nichts wusste.
Ich halte die übertriebene Abwehrhaltung gegen Duplikation für ein Problem unserer Zeit. Alle werden gleich, essen dasselbe, arbeiten in ähnlichen Berufen und bewegen sich entlang ähnlicher Bedürfnisse. Wenn man Botschaften wie „Erfinde das Rad nicht neu“ bis zum Extrem treibt, könnte das Endziel am Ende sein, zu einem unwissenden Menschen zu werden, der nur noch die spezialisierten Bedürfnisse einiger weniger Reicher bedient. Ein Leben, in dem man weder Kochen noch Landwirtschaft noch sogar Liebe noch lernt.
Ist ein Unternehmen ein Ort, an den man kommt, um zu lernen? Oder ein Ort, an dem man mit einem von anderen gebauten Rad Wert neu erschafft?
Das Bauen ist erst der Anfang, und wenn man einen Service etwa zehn Jahre lang betreibt, passiert unterwegs alles Mögliche — um das durchzustehen, braucht man ein Fundament ... Man muss lernen.