Der Fluch des Entwicklers: Unendliche Verantwortung für alle, die Dinge reparieren können
(notashelf.dev)- Wenn man kleine Automatisierungen immer wiederholt, erreicht man irgendwann einen kognitiven Kipppunkt, an dem alle Tools und Systeme wie etwas erscheinen, das repariert werden muss
- Je mehr technisches Können man aufbaut, desto mehr geht es über das bloße Erkennen von Problemen hinaus und bekommt das emotionale Gewicht, sich wie Verantwortung anzufühlen
- Der Drang, etwas reparieren zu wollen, dient nicht nur der Produktivitätssteigerung, sondern wird manchmal auch zu einem Mittel der Emotionsregulation und führt mitunter dazu, dass man sich im eigenen System gefangen hält
- Systeme gehen mit der Zeit zwangsläufig kaputt, und die Illusion einer vollkommenen Lösung existiert nicht
- Die wirklich nötige Fähigkeit ist am Ende nicht, alles reparieren zu können, sondern die innere Gelassenheit, etwas auch einmal nicht zu reparieren
Der Anfang mit kleinen Automatisierungen
- Es beginnt mit kleinen Produktivitätsverbesserungen wie einem Python-Skript zum Umbenennen von Dateinamen oder Abkürzungen für
git-Befehle - Hat man die Unbequemlichkeiten eines Systems einmal selbst behoben, beginnt plötzlich alles auf der Welt wie etwas zu wirken, das verbessert werden sollte
- Irgendwann wird aus „ich kann das“ nicht nur „ich sollte das tun“, sondern ein moralischer Zwang
Das Gewicht technischer Kompetenz
- Vor dem Programmieren konnte man umständliche Software einfach hinnehmen, doch jetzt sind die Probleme glasklar sichtbar
- Schlampiger Code anderer Entwickler oder hartkodierte Konfigurationen fühlen sich fast wie ein Vorwurf an
- Es findet ein Wahrnehmungswandel statt, bei dem alle Systeme und jede Software wie eine TODO-Liste von Dingen erscheinen, die repariert werden müssen
Ein Leben im ständigen Refactoring
- Mit dem Gedanken „Das kann ich besser bauen“ verliert man sich immer wieder in der Entwicklung eigener Tools
- Unaufgeräumte Code-Verzeichnisse, zahllose Versuche und aufgegebene Ansätze sowie endlose strukturelle Neuentwürfe werden mitunter zu selbstfesselnder Arbeit
- Wie in Kafkas Metapher vom „einen Käfig bauen und auf den Vogel warten“ kann man sich in zielloser Tool-Entwicklung verlieren
Software verrottet
- Selbst ein scheinbar perfektes Skript wird irgendwann durch äußere Veränderungen nutzlos
- Änderungen am Website-Layout, neue Paketversionen, Abhängigkeitsfehler usw.
- Wenn Probleme auftreten, fühlt es sich nicht einfach nur lästig an, sondern erzeugt Schuldgefühle
- Am Ende steht man der Realität gegenüber, dass kontinuierliche Pflege nötig ist
Die Illusion der Automatisierung
- Man klammert sich oft an die falsche Hoffnung, dass man etwas „nur einmal einrichtet und danach nie wieder anfassen muss“
- Programmieren wirkt wie ein Sieg der Problemlösung, ist aber in Wahrheit nur ein endloser Krieg
- Es gibt keinen Zustand der Vollendung; man gräbt nur immer weiter Schützengräben, die ständig volllaufen
Wenn Coding zum Mittel der Emotionsregulation wird
- Der Akt, Tools zu bauen, ist manchmal eine psychologische Reaktion, um das Chaos des Lebens kontrollieren zu wollen
- Je komplexer das System wird, desto mehr hat man paradoxerweise das Gefühl, selbst geordnet zu sein
- Um einem komplizierten Leben zu entkommen, probiert man neue Apps oder Refactorings aus und beruhigt sich damit selbst
Burnout ohne Vorwarnung
- Burnout entsteht nicht nur durch Überarbeitung, sondern vor allem aus einem übersteigerten Verantwortungsgefühl
- Die Selbstanklage „Warum repariere ich nicht, was ich doch reparieren könnte?“ verstärkt den Stress
- Die endlose technische Verantwortung wirkt als selbstzerstörerische Last
Lernen loszulassen
- Nicht jedes Problem muss gelöst werden
- Manchmal ist die Einsicht, dass man etwas nicht reparieren muss, die größere Form von Kontrolle
- Fehler anzuerkennen und etwas einfach weiter zu benutzen, kann ebenfalls eine bewusste Entscheidung sein
Die wahre Fähigkeit ist emotionale Klarheit
- Wichtiger als die Fähigkeit zu reparieren ist die innere Fähigkeit, nicht reparieren zu müssen
- Zu erkennen, wann man aufhören sollte und welche Projekte nur der Selbstberuhigung dienen
- Es braucht eine Haltung, die sich vom Zwang löst, alles reparieren zu wollen, und selbst in der Unvollkommenheit Gelassenheit findet
Am Ende ist die schwierigste Fähigkeit beim Programmieren,
„zu lernen, kaputte Dinge einfach kaputt sein zu lassen“
21 Kommentare
Alles hat einen Zweck. Wenn der Zweck erreicht ist, muss man es nicht weiter reparieren. Wurde der Zweck jedoch nicht erreicht, muss man es reparieren.
Der Anfang besteht wohl darin, den Zweck des Projekts klar zu erfassen.
Es ist leichter, wenn man sich klarmacht, dass es sogar Unternehmen mit einem Wert in Milliardenhöhe gibt, die allein dadurch entstehen, dass sie chaotische APIs von Banken und Zahlungsanbietern bündeln und ordnen. haha
Ku..
Wenn Sie beim Anblick eines Systems, das mit VB 6.0 und COM + OLE + ActiveX gebaut wurde und immer noch problemlos läuft, entsetzt sind und den Drang verspüren, es neu zu schreiben, dann werden Sie leiden.
Letztlich ist die schwierigste Fähigkeit beim Programmieren, „zu lernen, etwas Kaputtes einfach kaputt sein zu lassen“.
Dem stimme ich zu. Ich bin der Typ, der immer Dinge anfängt, und habe deshalb ständig zu kämpfen...
Eine von irgendeinem Programmierer hastig zusammengeschusterte Automatisierung wird natürlich früher oder später kaputtgehen.
Guter Inhalt
Burnout-Dotem
: Wenn man mühsam die Arbeit automatisiert hat, profitiert der Kollege nebenan davon, während man selbst direkt für die Automatisierung anderer Aufgaben eingesetzt wird;
Ich gehöre zu den Leuten, die eine Aufgabe, die 15 Minuten dauert, in 2 Tagen automatisiert haben und dann als Gehaltsschmarotzer gelten.
Dieses übertriebene Verantwortungsgefühl ist so etwas wie eine Berufskrankheit von Programmierern, deshalb muss man es systemisch lösen.
Das sollte das Quality-Assurance-Team absichern.
Kann QA die übermäßige Verantwortung von Entwicklerinnen und Entwicklern wirklich eindämmen? Ich verstehe das nicht so ganz.
Wenn sich bei Entwicklerinnen und Entwicklern Vorwürfe wie „Du hast falsch programmiert“ ansammeln und dabei nach Verschulden gefragt wird,
werden sie von Verantwortungsgefühl erdrückt, meiden neue Versuche
und schreiben am Ende nur noch sicheren Code ohne Weiterentwicklung.
Genau das ist damit gemeint, dass QA absichern soll.
Wenn man zukunftsgerichtet programmieren will, geht man zwangsläufig ein gewisses Risiko ein,
und QA sollte genau die Rolle übernehmen, das zu prüfen und dafür Verantwortung zu tragen.
So kann man diesen Artikel also auch lesen? Ich dachte, wenn man es genau nimmt, ist dieser Artikel eher eine Kritik am Yak Shaving.
Wie roxie sagte, geht es im Haupttext tatsächlich um Yak Shaving,
aber ausgehend von meiner persönlichen Erfahrung ist meine Bemerkung zu einer Geschichte geworden, die sich etwas vom Inhalt des Haupttexts unterscheidet.
Lässt sich das nicht auch mit dem NIH-Phänomen (not invented here) erklären? Ich denke, man sollte nicht vergessen, dass Wartung letztlich Fixkosten bedeutet und dass zu diesen Kosten auch der menschliche Aufwand zählt.
Um das hier lange zu machen, scheint es nötig zu sein, beizeiten auch zu üben, das Gewicht von Verantwortung und Gefühlen abzulegen, bevor man durch ein übersteigertes Verantwortungsgefühl in den Teufelskreis eines Kompensationsbedürfnisses gerät. Damit kann ich selbst auch nicht besonders gut umgehen, haha ... guter Text.
Ich finde, das ist ein guter Punkt. Verantwortung bedeutet wörtlich, Verantwortung zu empfinden, und verlangt daher an sich keine Gegenleistung. Mit der Zeit jedoch erschöpfen Körper und Geist, während dieses Verantwortungsgefühl nicht so leicht verschwindet, und um diese Lücke zu füllen, beginnt man offenbar, sich eine Gegenleistung zu wünschen (obwohl man beides eigentlich nicht miteinander verknüpfen sollte). Ohne es selbst zu merken.
Nun, ein etwas besserer Kompromiss als „Kaputtes einfach liegen zu lassen“ wäre wohl: „Fass es nicht an, bis es kaputtgeht“ :)
Hacker-News-Kommentare
Es gibt ein Zitat, das ich beim Theater gelernt habe. Es beschreibt den Prozess der Kunst so: Schwieriges zur Gewohnheit machen, Gewohntes leicht machen und Leichtes schön machen
Es wird eine persönliche Meinung zu UI-Problemen geäußert
Es wird Frust über Schwierigkeiten bei persönlichen Projekten geäußert
Es wird Respekt gegenüber Softwareingenieuren ausgedrückt
Es wird Kritik an Perfektionismus geäußert
Es werden persönliche Einsichten geteilt
Es wird erwähnt, dass Familie und Kinder dabei helfen, Perfektionismus zu überwinden
Selbst Software zu schreiben macht mehr Spaß und ermöglicht einfachere Lösungen
Es wird behauptet, dass die Kultur der Fixierung auf Neues die Wurzel des Problems ist
Psychologen teilen Menschen in solche ein, die maximieren, und solche, die nach etwas „gut genugem“ suchen
Statt „Kaputtes einfach kaputt zu lassen“ scheint „zu lernen, Unwichtiges loszulassen“ die passendere Formulierung zu sein.
Was unbedingt behoben werden muss, muss man natürlich beheben.
Dem kann ich zustimmen. Ich denke, man muss genau wissen, ob man gerade nur seinen Garten hübscher gestaltet oder tatsächlich an einer wichtigen Aufgabe arbeitet, und dann auch loslassen können.