Die Sache zu tun, ist die Sache zu tun

• Es wird betont, dass nur das eigentliche Handeln wirkliche Ausführung ist und dass Denken oder Vorbereitung keine Ausführung darstellen
• Wiederholt wird darauf hingewiesen, dass Planen, Lernen, Diskutieren und das Kaufen von Werkzeugen nicht dasselbe sind wie „die Arbeit zu tun“
• Nur das direkte Ausprobieren, selbst wenn man dabei scheitert oder ungeschickt ist, gilt als echte Ausführung
• Es ist wichtig, auch im Kleinen anzufangen, und perfekte Vorbereitung oder ideale Bedingungen sind unnötig
• Der Text erinnert daran, dass die Haltung, Dinge tatsächlich in die Tat umzusetzen, der Kern von kreativem Arbeiten und Entwicklung ist

---

Die Unterscheidung zwischen Ausführung und Nicht-Ausführung

• Der Text zählt auf, dass „denken, träumen, visualisieren, sich vorbereiten“ und Ähnliches alles nicht „die Arbeit zu tun“ ist
  • Beispiele: „nachdenken“, „träumen“, „sich den Erfolg vorstellen“, „warten, bis man bereit ist“
• Auch sprechen, erklären oder diskutieren wird nicht als Ausführung betrachtet
  • Dazu gehören „es anderen erklären“, „online darüber streiten“ und „ankündigen, dass man anfangen wird“

Die Falle von Vorbereitung und Konsum

• Podcasts hören, Tutorials ansehen, Fallbeispiele anderer lesen — all das ist keine Ausführung
• Auch ein perfektes System zu entwerfen, Werkzeuge zu kaufen oder den Arbeitsplatz aufzuräumen wird nicht als Ausführung angesehen
• Ebenso ist die Haltung, sich mit Schuldgefühlen oder Beschäftigtsein zu trösten, kein wirkliches Handeln

Formen echter Ausführung

• Es trotz Scheiterns zu tun, es ungeschickt zu tun und es auch nur im Kleinen zu tun — all das wird als „die Arbeit zu tun“ anerkannt
  • Wichtig ist, die Hände tatsächlich zu bewegen, auch wenn es nicht perfekt ist
• Im späteren Teil des Textes heißt es sogar, dass selbst das Schreiben eines Blogposts nicht bedeutet, die Arbeit zu tun, was zu einem selbstreflektierenden Schluss führt

Die Kernbotschaft

• Nur Handeln ist echte Ausführung, alles andere ist kein Ersatz dafür
• Auch klein anzufangen, das Scheitern in Kauf zu nehmen und es selbst zu tun ist der einzige wirkliche Fortschritt
• Der letzte Satz des Textes, „Jetzt sollte ich wieder an die Arbeit gehen“, steht sinnbildlich für eine Haltung der sofortigen Umsetzung

[bobross0]

Ein guter Satz für Menschen wie mich, die nicht gut darin sind, Dinge tatsächlich umzusetzen.

[GN⁺]

Hacker-News-Kommentare

• Das Prinzip „es schlecht zu machen“ hat meine Denkweise komplett verändert.
  Ich habe Wochen damit verbracht, die perfekte Architektur zu entwerfen, aber am Ende habe ich mit dem Planen aufgehört und eine holprige Version gebaut, die mein Problem löst.
  Das Überraschende war, dass mir diese erste Version Dinge beigebracht hat, die ich durch Planung nie hätte lernen können: was Nutzer tatsächlich wichtig finden, welche Edge Cases in der Praxis zählen und was „gut genug“ wirklich bedeutet.
  Am schwersten ist es, einen Release freizugeben, obwohl man weiß, dass er Mängel hat. Aber die Feedback-Schleife aus echter Nutzung war viel wertvoller als wochenlange hypothetische Diskussionen.

  • Ich stimme dem Inhalt zu, aber der Ton klingt wie von einem LLM erzeugt.
    Solche Posts gibt es inzwischen massenhaft in produktivitätsbezogenen Subreddits. Ich bezweifle, dass es realistisch ist, beim Bauen eines persönlichen Automatisierungstools wochenlang die Architektur zu planen.
    Wenn man sich die Kommentarhistorie des Autors ansieht, wiederholt sich ein ähnlicher Stil ständig, was nicht gerade Vertrauen schafft.
  • Ein großartiger Entwickler, den ich früher gesehen habe, arbeitete so, dass er den Code mehrfach komplett löschte und neu schrieb.
    Diesen Prozess zu beobachten war wirklich faszinierend.
  • Es ist wirklich schwer, Anfängern dieses Gefühl beizubringen.
    Beim tatsächlichen Implementieren und Refaktorieren lernt man enorm viel über das Problem und über Programmierung allgemein.
    Die erste Abstraktion, die man sich ausdenkt, ist meistens falsch. Beim Implementieren verändert sich die Struktur komplett, und am Ende entsteht schöner Code, der mit dem Anfang kaum noch etwas zu tun hat.
  • Das erinnert mich an den Essay „Plan to Throw One Away“ aus Fred Brooks’ The Mythical Man-Month.
    Die Idee ist, die erste Version mit der Erwartung zu bauen, sie wegzuwerfen, aber in der Praxis wirft man sie meist nicht weg, sondern verbessert sie iterativ.
    Heute können wir dank Tools und Prozessen ständig iterieren.
  • Wichtig ist, das Design der übergeordneten Funktionen nicht mit dem internen Plumbing zu verwechseln.
    Auch die interne Struktur braucht Iteration und Prototyping, aber Dinge wie Datenstrukturen, Error Handling, Logging und Naming sollte man früh mit Bedacht festlegen, damit man später schneller verbessern kann.

• Ich mag den Satz „Doing it badly is doing the thing“.
  Das ist eine Lektion, die ich bei HN gelernt habe: Wenn man feststeckt, sollte man nicht darüber grübeln, wie man es perfekt macht, sondern einfach anfangen.
  Anfangs ist es vielleicht chaotisch, aber wenn man es Stück für Stück verbessert, sieht man plötzlich ein klares Bild. Es wirkt fast wie Magie.

  • Der Satz „Everything worth doing is worth doing badly“ hat mir durch schwierige Zeiten geholfen.
  • Dazu passen zwei Ratschläge, die ich sehr mag.
    Einer ist Dan Harmons Rat gegen writer’s block,
    der andere ist Ira Glass’ „The Gap“.
    Der Kern ist: Warte nicht auf Perfektion, sondern schreibe erst mal einen miserablen Entwurf und überarbeite ihn dann mit dem Blick eines Kritikers.
  • Im Unternehmen bekommt man bei so einem Ansatz eher zu hören: „Das reicht schon so“, und dann bleibt die unfertige Version für immer bestehen.
    Deshalb sage ich inzwischen absichtlich „noch nicht fertig“, bis es wirklich fertig ist.
  • Software durchläuft normalerweise die drei Phasen alpha–beta–release.
    Ich mache es meist so, dass ich zuerst schnell etwas baue, es dann überarbeite und es am Ende noch einmal neu schreibe.
    Entscheidend ist, in der Beta-Phase nicht in Perfektionismus zu verfallen.
  • Es ist interessant, dass Menschen positiv beurteilt werden, wenn sie sich auf diese Weise schrittweise verbessern, während LLMs dafür negativ gesehen werden.
    Wenn schrittweise Verbesserung tatsächlich wirksam ist, spielt es eigentlich keine Rolle, ob sie von Menschen oder von KI kommt.

• In einer früheren Firma nannten wir das Management den „Verein zur Bewunderung von Problemen“.
  Es war besessen davon, Probleme zu diskutieren, zu analysieren und Verantwortliche zu finden, hat sie aber nie wirklich gelöst.
  Am Ende zählte nur, es tatsächlich zu tun.

  • Umgekehrt gibt es Firmen, die an bestehenden Lösungen festkleben und das Problem selbst nicht noch einmal anschauen wollen.
    Der beste Ansatz ist, sowohl Interesse am Problem als auch den Willen zur iterativen Lösung mitzubringen.
    Dogfooding im eigenen Haus ist eine gute Methode, dieses Gleichgewicht herzustellen.
  • Wenn man am Ende die Person ist, die die Arbeit wirklich macht, sollte man diese Entscheidungsmacht nutzen.
    Wichtig ist, Entscheidungen möglichst in eine Richtung zu lenken, die einem selbst hilft.
  • Wenn man mittleres Management entfernt, steigt die Produktivität.
    Es gibt weniger Abstimmung für Statusupdates, und eine Organisation, die tatsächlich arbeitet, ist effizienter.
  • Wenn man nach der Analyse einen guten Grund hat, jetzt sofort etwas anderes anzufangen, ist das auch in Ordnung.

• Dieser Text ist dem Essay auf strangestloop.io sehr ähnlich.

  • Ehrlich gesagt wirkt es fast wie Plagiat.
    Der Titel kam mir bekannt vor, aber als ich klickte, war es eine andere Website, und das Veröffentlichungsdatum lag nur ein paar Tage zurück, was mich überrascht hat.
    Der Inhalt ist so ähnlich, dass Zufall schwer zu glauben ist.
  • Ich konnte mich auch nicht mehr erinnern, wo ich das schon gesehen hatte, aber ich wusste, dass ich schon einmal etwas sehr Ähnliches gelesen hatte.

• Früher dachte ich, Vorbereitung sei wichtig, aber irgendwann habe ich gemerkt, dass Vorbereitung zu einer Endlosschleife werden kann.
  Unser Team hat mit einer zweiseitigen Spezifikation in vier Monaten ein Produkt fertiggestellt, während ein konkurrierendes Team acht Monate lang nur Dokumente schrieb und dann aufgelöst wurde.
  Mit 20 % Planung fängt man 80 % der Probleme ab. Alles darüber hinaus ist oft nur als Strenge verkleidete Unsicherheit.
  Das meiste habe ich am Ende dadurch gelernt, dass ich etwas Peinliches veröffentlicht und dann verbessert habe.

  • Ich glaube, du missverstehst den Punkt des Textes ein wenig. Schon Vorbereitung selbst gehört zu dem, was nicht „doing the thing“ ist.
  • Das hängt vom Team ab. Unser Team hat monatelang geplant und trotzdem gut ausgeliefert. Letztlich kommt es auf den Kontext an.
  • Der Nutzen von Planung nimmt zwar ab, aber die meisten Projekte scheitern eher an zu wenig Planung.
  • Das erinnert mich an Rimmer aus Red Dwarf, der beim Prüfungsvorbereiten scheitert, weil er immer nur weiter vorbereitet.
    Es wurde in einem früheren HN-Kommentar zitiert.
  • Planung komplett abzuschaffen ist ebenfalls ein Problem. Man braucht Balance.

• Analysis paralysis ist real.
  Wenn man nicht stehen bleiben will, muss man einfach anfangen. Erledige zuerst den Happy Path und glätte die Edge Cases später.
  Heute sind die Kosten für Prototypen niedrig, also sollte man ausprobieren, ohne Angst vor dem Scheitern zu haben.
  Genau deshalb sind LLMs so erstaunlich effektiv — sie führen sofort aus, statt zu analysieren.
  Auch wenn das Ergebnis nicht perfekt ist, ist es oft gut genug, und falls nötig kann man später optimieren.
  Bevor man ein Framework baut, sollte man mindestens dreimal ein echtes System gebaut haben. Erst dann weiß man, wo etwas übertrieben oder unzureichend ist.

  • Man darf allerdings einen Prototyp nicht mit einem echten Produkt verwechseln.
    „Gut genug“ kann leicht zu Selbsttäuschung werden.
    Ein gescheiterter Prototyp ist kein Beweis dafür, dass es keinen Markt gibt. Er ist nur ein Signal, dass etwas gefehlt hat.

• Dieser Text transportiert fast dieselbe Botschaft wie der frühere Beitrag.
  Er wurde auch in einer früheren HN-Diskussion behandelt.

  • Die Diskussion ist so ähnlich, dass man sie fast als Duplikat (dupe) markieren müsste.

• Umgekehrt gibt es aber auch Fälle, in denen „doing the thing“ selbst die falsche Entscheidung ist.
  Deshalb halte ich weiterhin an Designdokumenten und Code Reviews fest.
  Im Zeitalter von GenAI ist es zu einfach geworden, ohne Planung einfach irgendetwas hinzuschreiben, deshalb braucht es umso mehr Gegengewicht.

  • Heute ist zwar der Happy Path einfacher geworden, aber die Lücke zwischen Prototyp und Produktion ist größer.
    Man verliert seine Zeit an Nichtdeterminismus und Latenzproblemen, und am Ende ist die eigentliche Herausforderung, die Unit Economics tragfähig zu machen.

• In Remains of The Day wird „nur über die Sache zu reden“ als selbstgefällige Handlung bezeichnet.
  Oft sind das Gespräche, bei denen man sich gut fühlt, obwohl in Wirklichkeit nichts erreicht wird.

• Andererseits können Planung, Vorbereitung und mise-en-place der tatsächlichen Ausführung helfen.

  • Allerdings nur, wenn daraus wirklich Handeln folgt. Man darf nicht in Analyseparalyse verfallen.
  • Menschen verwechseln Planung oder Diskussion oft mit „doing the thing“. Genau das ist das Problem.