Repariere zuerst deine Werkzeuge

• Beim Nachverfolgen eines Bugs in einer Open-Source-Bibliothek trat das Problem auf, dass der Debugger nicht funktionierte
• Obwohl der Code ausgeführt wurde, wurden Breakpoints ignoriert, sodass versucht wurde, das Problem auf anderem Weg zu finden
• Es wurden indirekte Diagnoseversuche unternommen, etwa durch zusätzliche Log-Ausgaben, doch die gewünschten Erkenntnisse blieben aus
• Nachdem schließlich ein Konfigurationsfehler im Debugger behoben wurde, ließ sich das Verhalten des Programms detailliert beobachten, wodurch der Bug gelöst werden konnte
• Die Erfahrung, aus lauter Fokus auf die Problemlösung den Defekt des Werkzeugs selbst übersehen zu haben, unterstreicht, dass Entwickler zuerst ihre Werkzeuge reparieren sollten, um Probleme effizient zu lösen

---

Probleme während der Bug-Diagnose

• Beim Aufspüren eines Bugs in einer gepflegten Open-Source-Bibliothek ignorierte der Debugger Breakpoints
  • Es war sicher, dass der Code die betreffende Zeile ausgeführt hatte, doch das Programm lief ohne Unterbrechung bis zum Ende
  • Weil der Fokus ganz auf der Problemlösung lag, wurde das Debugger-Problem ignoriert und andere Ansätze wurden ausprobiert
• Es wurden Änderungen am Code und Diagnoseversuche per zusätzlichem Logging vorgenommen, aber ohne nützliche Erkenntnisse

Den Debugger reparieren und das Problem lösen

• Es fiel die Entscheidung, das Debugger-Problem zu beheben, was mit einer einzeiligen Konfigurationsänderung gelang
  • Danach ließ sich das Verhalten des Programms im Detail beobachten
  • Auf dieser Grundlage konnte der Bug erfolgreich behoben werden

Einsicht und Lehre

• Es wurde die paradoxe Situation erkannt, dass der Eifer, einen Bug zu beheben, gerade dazu führte, das Problem am Werkzeug zu übersehen
• Es wurde unmittelbar erfahren, dass eine nicht korrekt funktionierende Tooling-Umgebung die Effizienz bei der Problemlösung senkt
• Was Entwickler brauchen, ist die Gewohnheit, vor dem eigentlichen Problem zuerst die Werkzeuge zu prüfen und zu reparieren
• Mit dem Satz „Fix your tools“ endet der Text als Erinnerung an alle Programmierer, wie wichtig funktionierende Werkzeuge sind

[GN⁺]

Hacker-News-Kommentare

• Ich bin seit 30 Jahren im Beruf, und Entwicklungswerkzeuge sind heutzutage viel zu kaputt
  Ich schreibe unter Linux Code mit Clio, und die Bugs werden seit Jahren immer schlimmer
  Inzwischen gehe ich einfach darüber hinweg nach dem Motto: „Wenn es nicht geht, dann geht es eben nicht.“ Das Leben ist kurz, und ich habe keine Zeit, auch noch fremden Code zu reparieren

• Wenn man versucht, ein Problem zu beheben, gerät man am Ende oft ins „yak shaving“
  Beim Lösen eines kleinen Problems zieht eine Kette immer detaillierterer Aufgaben nach sich
  Das dazugehörige Video gibt es hier

  • In solchen Situationen gibt es keine richtige Antwort
    Manchmal explodiert die Produktivität geradezu, wenn man Werkzeuge und Bibliotheken aufräumt, und ein andermal ist es einfach schneller, es per Hardcoding durchzuziehen
    AI hilft zwar dabei, Werkzeuge zu verfeinern, aber gleichzeitig wächst auch der Umfang, sodass man am Ende genauso viel Zeit für Tooling aufwendet
    Letztlich ist es ein Problem von emotionaler Prokrastination. Entweder wiederholt man kleine Änderungen, weil man nicht über die Gesamtstruktur nachdenken will, oder man schiebt die Gesamtarchitektur auf und feilt stattdessen nur an Detailwerkzeugen
  • Schade ist, dass „yak shaving“ oft als bloße Zeitverschwendung missverstanden wird
    Tatsächlich ist es auch ein Prozess, mit notwendiger Reibung und Unbequemlichkeit umzugehen
    Man sollte aber immer prüfen, ob diese Unbequemlichkeit wirklich nötig ist
    10 bis 15 Minuten darin zu investieren, wiederkehrende Arbeit zu automatisieren oder abzukürzen, heißt letztlich, sich Zeit in der Zukunft zu kaufen
  • Das Video war wie erwartet, aber trotzdem lustig
  • Musste auch an XKCD 349 denken
  • Der Grund, warum so etwas passiert, ist, dass die Werkzeuge zu sehr vernachlässigt wurden und deshalb alle kaputt sind
    Technische Schulden müssen irgendwann ohnehin bezahlt werden, also sollte man sich angewöhnen, sie nach und nach abzutragen

• Engineering ist am Ende eine fortlaufende Übung im Schärfen der Axt
  Ich mag den Ansatz von Kent Beck: „Mache zuerst Veränderungen leicht, und mache dann die leichten Veränderungen.“

  • Ich sollte zum ersten Mal fremden Code verbessern, aber der Zustand war so schlimm, dass ich mich am Ende zuerst für Refactoring entschieden habe
    Es war viel befriedigender, den Code zu verbessern, als einfach nur eine Funktion hinzuzufügen
  • Bei AI-basiertem Coding ist dieser Ansatz noch unzureichend
    AI findet es nicht seltsam, denselben Code mehrfach zu wiederholen, daher entstehen weder Strukturierung noch Wiederverwendung
  • Eine Axt gleich zu Beginn vier Stunden lang zu schärfen, ist womöglich ineffizient
    Realistischer ist es, sie während der Arbeit erneut zu schärfen, wenn sie stumpf wird
  • Beim Programmieren bevorzuge ich die „Axt“ (minimale Werkzeuge wie vim), aber beim Bäumefällen ist eine Kettensäge doch deutlich besser
  • Die meisten Kollegen arbeiten, als würden sie Holz mit einem Rohr schneiden
    „Ich bin gerade zu beschäftigt, um die Axt zu schärfen!“, und so arbeiten sie weiter ineffizient

• Der Satz „Der Drang, Bugs zu beheben, verdeckt eher die Tatsache, dass man zuerst die Werkzeuge reparieren muss“ ist mir besonders im Gedächtnis geblieben
  Kenneth Stanleys Why Greatness Cannot Be Planned behandelt dieses Phänomen ebenfalls

• Großartiger Rat. Ich versuche auch, das jeden Tag umzusetzen
  Aber den Anschlussrat – „Jetzt hör auf, die Werkzeuge zu reparieren, und behebe das eigentliche Problem“ – befolge ich nicht besonders gut

• Ich gerate auch oft in solche Situationen
  Wenn man kleine Reibungsverluste behebt, spart man später Zeit, aber es gibt die Falle, dass man endlos nur an Werkzeugen herumbastelt
  Das wirklich Schwierige ist der Punkt, an dem man entscheidet: „Das reicht jetzt“ und macht weiter

• Werkzeuge haben einen Hebeleffekt auf den eigenen Aufwand
  Aber es ist schwer, das Gleichgewicht zwischen „yak shaving“ und unnötiger Handarbeit zu finden
  Wenn man plant, langfristig mit denselben Werkzeugen zu arbeiten, könnte man vielleicht stärker zum yak shaving tendieren, als man denkt, weil selbst eine Verbesserung um 1 % kumulativ viel ausmacht

• Die wichtigste Lektion ist, dass All-in-One-Tools meistens nichts taugen
  Ich habe für Content-Pipelines no-code-Tools wie Make, Airtable und n8n ausprobiert, aber ab einer gewissen Größenordnung brechen sie alle auseinander
  Am Ende war es viel stabiler, API-Aufrufe direkt mit Python-Skripten zu machen
  Die eigentliche Lösung war nicht, komplexe Tools zu reparieren, sondern sie durch einfache und transparente Werkzeuge zu ersetzen

  • Ich habe Tools wie n8n noch nie benutzt und frage mich, ob es Fälle gibt, in denen sie besser als Python sind
  • Deshalb mag ich Airflow wirklich sehr

• Mit dem Debugger den Codefluss direkt zu beobachten ist sehr nützlich
  Das ist viel intuitiver verständlich als statische Analyse

  • Aber ein Debugger ist nicht immer hilfreich
    Wenn man ständig Variablen oder Breakpoints verändert, verliert man leicht das eigentliche Problem aus dem Blick
    Einen Debugger sollte man nur zum Überprüfen von Hypothesen verwenden. Sonst gerät man in die Illusion, Fortschritte gemacht zu haben

• Wenn dir solche Texte gefallen, möchte ich scherzhaft sagen: Installiere auf keinen Fall Emacs