Das Geständnis eines Softwareentwicklers: Keine Selbstzensur mehr

• Ein Entwickler, der aus Angst monatelang mit Schreiben und Online-Aktivitäten aufgehört hatte, beschließt, mit der Selbstzensur aufzuhören und technische wie persönliche Defizite einzugestehen, die er sich bisher nicht eingestehen konnte
• Er räumt ein, das Konzept der Polymorphie (polymorphism) über mehr als zehn Jahre nicht verstanden zu haben, seine SQL-Kenntnisse verloren zu haben und den Großteil seines Codes ohne automatisierte Tests ausgerollt zu haben
• Er beschreibt, wie er beim Versuch, mit dem Wechsel des Tech-Stacks seines Unternehmens Schritt zu halten, das Lernen von C# und Blazor abbrach, wie er Ruby noch immer liebt, es beruflich aber nicht nutzen kann, und welche psychische Belastung er empfindet, wenn Manager und Kollegen seinen Blog lesen
• Er schildert seine Erfahrung mit Cybermobbing nach dem Einreichen eines mit KI verfassten PRs sowie seine ehrlichen Gefühle zur Remote-Arbeit und seine offene Meinung zur Überflüssigkeit maßgeschneiderter Entwicklungsprozesse innerhalb von Organisationen
• Am Ende steht der Vorsatz, die Angst loszulassen und auch künftig kontinuierlich zu lernen und öffentlich zu schreiben — ohne weitere Selbstzensur

---

Anfang: Der Auslöser, Angst und Selbstzensur zu beenden

• Seit April gab es eine Zeit, in der die Angst so groß war, dass er nichts mehr posten konnte, und er kappte alles — von Social Media über News-Aggregatoren bis hin zu Foren
  • Er hatte das Gefühl, dass es so nicht weitergehen könne, und entschied sich, die Angst zu überwinden und wieder zu schreiben
• Er wollte seine schwachen Grundlagen nicht offenlegen und hielt sie krampfhaft verborgen, begann aber zu erkennen, dass viele Entwickler mit ähnlichen Wissenslücken arbeiten
  • Seine bisherige Art zu lernen ähnelte einem Schleimpilz, der nur in den Bereichen übermäßig wächst, die er tatsächlich nutzt, während ungenutztes Wissen einfach vertrocknete
• In letzter Zeit begann er wieder, seine Grundlagen aufzufüllen, und während er Gelerntes in Texten und Gesprächen neu formulierte, entstand allmählich das Gefühl, leicht eingestehen zu können: „Ich weiß es nicht“
• Indem er selbst erlebte, dass man Grundlagen erneut lernen kann, entwickelte er die Überzeugung, dass es nie zu spät ist

Die Jahre, in denen er Polymorphie über mehr als ein Jahrzehnt nicht verstand

• Seit 2012 glaubte er, objektorientierten Code zu schreiben, musste sich aber eingestehen, dass er bis noch vor etwa einem Jahr Polymorphie nicht wirklich verstanden hatte
  • Er sah sich mit der Realität konfrontiert, dass sein bisheriger Code weniger objektorientiert als vielmehr nahe an strukturierter Programmierung gewesen war
  • Die Idee, Bedingungen durch Klassen zu ersetzen und dadurch das Design zu verändern, war ihm nie gekommen
• Erst durch Texte von Sandi Metz und Material von Martin Fowler verstand er das Konzept verspätet und erkannte deutlich, wie viel er all die Zeit verpasst hatte

• Warum es schwer war, das offenzulegen

  • Es war belastend, offenzulegen, dass ausgerechnet jemand, der in Bewerbungsgesprächen die Bewertung objektorientierter Konzepte übernommen hatte, Polymorphie selbst nicht kannte
  • Dadurch wurde schonungslos sichtbar, dass er zu Beginn seiner Karriere stärker auf Tools als auf Prinzipien fokussiert gelernt hatte, und es war nicht leicht, sich der Tatsache zu stellen, dass ihm aufgrund seines nicht-informatischen Hintergrunds viele Grundlagen fehlten

Die Erfahrung, SQL vergessen zu haben

• Früher gab es eindeutig eine Zeit, in der er SQL-Bücher durcharbeitete, Übungsaufgaben löste und JOINs und Subqueries souverän schreiben konnte
• Als seine frontendzentrierte Berufspraxis andauerte und SQL vollständig aus seinem Alltag verschwand, merkte er irgendwann, dass eine ganze Fähigkeit aus seinem Kopf verschwunden war
  • Einfache Queries fallen ihm noch ein, aber um den Unterschied zwischen left join und outer join zu erklären, müsste er wieder die Dokumentation aufschlagen

• Warum es schwer war, das zuzugeben

  • Als Jüngerer glaubte er, dass Fakten und Fähigkeiten auch nach Jahren mit nur einem kleinen Hinweis wieder abrufbar würden
  • Inzwischen spürte er, dass diese Fähigkeit nicht unverändert geblieben war, und es traf ihn besonders, dass SQL die erste Fähigkeit war, die vollständig aus seinem Gedächtnis verschwunden war
  • Öffentlich über das Älterwerden und Veränderungen im Gedächtnisfluss zu schreiben, fiel ihm nicht leicht

Die Realität, ohne automatisierte Tests entwickelt zu haben

• Er gesteht sich ein, dass mehr als 95 % des von ihm ausgelieferten Codes ohne automatisierte Tests produktiv laufen
  • Zu Beginn seiner Karriere war ihm das Konzept von Tests gar nicht begegnet, und zu Ember-Zeiten war es schwierig, Testwerkzeuge sinnvoll zu nutzen
• In letzter Zeit arbeitete er oft mit Legacy-Code und konnte nicht genug Zeit in die Vorarbeit investieren, um den Code testbar zu machen
  • Nur in neu entstehenden Subsystemen konnte er Tests mit einfließen lassen

• Warum es schwer war, das offenzulegen

  • Diese Beichte fühlte sich so schwer an, dass sie ihm als die karriereschädlichste Tatsache erschien
  • Nach dem Maßstab von Uncle Bob ist Code, der ohne Tests in Produktion läuft, eine Haltung, die man als unethisch betrachten könnte, und er hatte Angst, sich der Kluft zwischen diesem Maßstab und seiner eigenen Realität zu stellen
  • Es schien sehr wahrscheinlich, dass eine Offenlegung zu Nachteilen in Bewerbungsprozessen führen würde, weshalb er selbst die Dokumentation seines Lernwegs aufschob

Warum er Blazor nicht gelernt hat

• Als das Unternehmen beschloss, von Angular auf Blazor umzusteigen, war er das einzige Teammitglied ohne Erfahrung in C# und begann eilig zu lernen, um den Rückstand aufzuholen
• Einige Monate später wurde die Umstiegsentscheidung zurückgenommen, und damit verschwand seine Lernmotivation vollständig; er las nicht einmal das Buch zu Ende und hörte auf
• C# oder .NET waren ohnehin keine Sprachen, die er in Side Projects einsetzen wollte, und es zeigte sich deutlich, dass er sie ausschließlich für die Arbeit gelernt hatte

• Warum es schwer war, das aufzuschreiben

  • In einem früheren Beitrag hatte er selbst ausdrücklich einen Folgeartikel versprochen, und es fühlte sich zunehmend unangenehm an, andere Texte zu schreiben, ohne dieses Versprechen eingelöst zu haben
  • Weil seine Blazor-Beiträge hohe Abrufzahlen erzielten, fürchtete er, dass das Eingeständnis des Kurswechsels wie eine Niederlage wirken könnte

Der Wunsch, mehr Ruby zu schreiben

• Ruby ist für ihn noch immer die angenehmste und freudvollste Sprache, zu der er bei Beispielen, Open Source, Katas und Hackathons ganz natürlich greift
• Seit 2013 hat er jedoch kein einziges Mal mehr Geld mit Ruby verdient, und beruflich verwendet er Sprachen wie TypeScript
• Weil er die Kollegen, mit denen er in verschiedenen Unternehmen gearbeitet hat, sehr schätzt, musste er immer wieder bei der Sprache Kompromisse eingehen, statt sich gegen die Menschen zu entscheiden
• Er würde seine Abende und Wochenenden gern Ruby widmen, doch andere Verpflichtungen und Lernziele drängen sich vor, sodass kaum genug Zeit bleibt, Ruby wirklich ausreichend zu nutzen

• Warum es schwer war, das offenzulegen

  • Sein Manager und sein CTO lesen diesen Blog, und er hatte Angst, dass die Aussage, er wolle mehr Ruby schreiben, als Signal für eine Kündigung gelesen werden könnte
  • Ebenso wollte er nicht als jemand erscheinen, der im Unternehmen eine Sprache durchdrücken will, mit der sonst niemand vertraut ist

Cybermobbing tut auch Erwachsenen weh

• Als er einem Open-Source-Projekt einen kleinen, mit einem LLM erzeugten Patch schickte und diese Erfahrung in einem Online-Forum teilte,
  wurde er plötzlich mit persönlichen Angriffen wie inkompetent, ekelhaft und bedrohlich überschüttet
• Die Angriffe blieben nicht auf die Website beschränkt, sondern setzten sich über andere Websites, E-Mail, SMS und Telefon fort, wodurch er ganz unmittelbar das Gefühl bekam, nicht sicher zu sein
• Er bat die Forenadministration, seinen Klarnamen zu entfernen, doch stattdessen wurden seinem Profil noch mehr PII hinzugefügt,
  und er sah sich sogar mit einem dauerhaft verankerten falschen Hinweis konfrontiert, er habe die Geschichte über externe Kontaktaufnahmen erfunden
• Am Ende blieb ihm nichts anderes übrig, als den Account zu deaktivieren und die Website zu verlassen

• Warum es schwer war, das aufzuschreiben

  • Das tagelange Mobbing war die toxischste Online-Erfahrung, die er je gemacht hatte, und die Nachwirkungen sind bis heute spürbar
  • Er fürchtet weiterhin, dass die Täter zurückkehren könnten, wenn er diese Geschichte öffentlich macht
  • Hinzu kam die Sorge, dass die falschen Informationen im Profil seinen Beschäftigungschancen schaden könnten, was das Sprechen darüber noch schwieriger machte

Warum ein SaaS-Team keinen „besonderen Prozess“ braucht

• In der Softwarebranche gibt es seit Jahrzehnten bereits ausgereifte Prozesse,
  und Ansätze wie Agile, Lean, Kanban und XP bestehen als bereits bewährte Strukturen
• Daraus ergab sich für ihn ganz natürlich die Einschätzung, dass Unternehmen ihre begrenzten Kräfte eher auf Produktentwicklung als auf die Erfindung neuer Prozesse verwenden sollten

• Warum es schwer war, diese Meinung auszusprechen

  • Er hat beim Schreiben die Gewohnheit, sich stets auf Themen zu stützen, die er gut kennt, und in diesem Fall war der Auslöser ein von einem Kollegen desselben Unternehmens vorgeschlagener maßgeschneiderter Softwareentwicklungsprozess
    • Er hatte das Gefühl, dass der Text leicht wie eine öffentliche Kritik an einer bestimmten Person oder deren Idee wirken könnte
  • Er bewundert an Autoren wie Kent Beck und Martin Fowler, dass sie bessere Formen der Zusammenarbeit erklären können, ohne dabei Kollegen frontal anzugreifen, die Fehler gemacht haben
    • Er selbst hatte das Gefühl, dieses Gleichgewicht noch nicht ausreichend zu beherrschen, und zögerte deshalb mit dem Schreiben

Wie Remote-Arbeit tatsächliche Zusammenarbeit behindert

• Remote-Arbeit löst viele Probleme, aber er kann das Gefühl nicht abschütteln, dass Softwareentwicklung selbst besser funktioniert, wenn man sich denselben Raum teilt
• Videocalls sind Kommunikation mit niedriger Bandbreite und geringer Sinnesdichte, und weil das periphere Wahrnehmen wegfällt, wird es schwerer, Schwierigkeiten von Kollegen rechtzeitig zu bemerken
• Auch darum ist es belastender, um Hilfe zu bitten, und räumliche Denkwerkzeuge wie Whiteboards oder Sticky Notes brechen in Online-Tools leicht auseinander
• Konflikte verschärfen sich schneller, weil Menschen auf dem Monitor leichter in ein Feindbild verwandelt werden

• Warum es schwer war, darüber zu schreiben

  • Seit Covid arbeitet sein Unternehmen vollständig remote, und genau dadurch konnte er ein Leben mit 27 Acres Land und sogar einer Familienmilchkuh aufbauen
  • Weil daraus eine Lebensstruktur entstanden ist, die sich kaum in eine Stadt verlagern lässt, fühlte es sich so an, als würde die Aussage, dass er Remote-Arbeit nicht bevorzugt,
    einen schlechten Eindruck im aktuellen Job und bei allen künftigen Remote-Bewerbungen hinterlassen

Wie es weitergeht

• Mit diesem Text hat er das Gefühl, wieder einen ersten Schritt über die Angst hinaus gemacht zu haben,
  und er plant, auch künftig an seinen Grundlagen zu arbeiten und alles Gelernte ohne Verbergen aufzuschreiben
• Menschen mit ähnlichen Erfahrungen, Menschen, die helfen möchten, und Menschen, die auf den nächsten Text warten,
  verweist er auf Mastodon, RSS und seine Mailingliste, um auf dem Laufenden zu bleiben

[GN⁺]

Hacker-News-Kommentare

• Ich habe etwas von einem sehr klugen Kollegen gelernt: Er fürchtet sich nicht davor, etwas nicht zu wissen und fragt immer weiter, bis er es versteht. Ich fand seine Zuversicht und Geduld, die man braucht, um öffentlich zu lernen, beeindruckend
• Mir gefielen die Bescheidenheit und Ehrlichkeit des Textes. Man muss sich nicht dafür schämen, etwas nicht zu wissen. Ich lerne seit 37 Jahren und eigne mir immer noch Neues an.
  Ich selbst bevorzuge zwar die Arbeit im Büro, aber das heißt nicht, dass ich RTO (Return to Office) befürworte. Das ist einfach nur meine persönliche Neigung.
  Die Unsicherheit und das Impostor-Syndrom in der Branche scheinen Menschen aggressiv zu machen. Wenn alle ehrlicher wären, wäre es wohl etwas entspannter.
  Und wenn ich schon gestehe: Ich habe in Lisp oder Haskell noch nie etwas Komplexeres als Fibonacci geschrieben. Mein Gehirn funktioniert dafür einfach nicht so
  • Ich bin zwar nicht deiner Meinung zur Remote-Arbeit, aber weil du es als persönliche Ansicht formuliert hast, finde ich das in Ordnung.
    Der Originaltext formuliert die eigenen Erfahrungen jedoch so, als wären sie eine objektive Wahrheit für alle. Besonders die Erzählweise in der zweiten Person wirkte auf mich arrogant.
    Wie man etwas sagt ist genauso wichtig wie der Inhalt selbst. Gerade bei sensiblen Themen wie Remote-Arbeit sollte man mit der Formulierung vorsichtig sein.
    Ich selbst musste wegen gesundheitlicher Probleme in der Familie remote arbeiten, deshalb wirkte der Ton des Textes auf mich leichtfertig und hat mich wütend gemacht.
    Bevor man also sagt, die Leute würden überreagieren, sollte man zuerst darüber nachdenken, welche Wirkung die eigene Ausdrucksweise hat
  • Ich konnte vor meiner Mitarbeit an einem Lisp-basierten Projekt auch nichts schreiben, was über Fibonacci hinausging. Als ich es täglich benutzt habe, wurde ich schließlich damit vertraut
  • Warum man beschimpft wird, wenn man sagt, dass man Remote-Arbeit bevorzugt? Weil Menschen seit Corona Freiheit gewonnen haben und nun das Gefühl haben, wieder eingeschränkt zu werden. Deshalb scheint der Widerstand so stark zu sein
  • Die heutigen YouTube-Coding-Gurus behaupten bei allem, im Recht zu sein. Es ist eine Welt, in der man angeblich alles falsch macht
• Immer wenn ich Gespräche über Remote-Arbeit höre, vermisse ich die IRC-Zeit. Damals funktionierte Remote-Zusammenarbeit bereits gut.
  Statt Flurgesprächen wurden Probleme im Team-Chat gelöst, und alle halfen aktiv mit.
  Heute habe ich eher das Gefühl, dass wir die Tools schlechter nutzen als damals
  • Heute gibt es viele Menschen, die Angst haben, in öffentlichen Kanälen zu schreiben. Früher gab es Anonymität, heute läuft vieles unter Klarnamen, deshalb sind die Leute vorsichtiger.
    Weil es weniger Räume gibt, in denen man anonym sprechen kann, ist eine Kultur entstanden, in der freies Sprechen schwieriger geworden ist
  • Früher war ich im Büro mit Slack deutlich effizienter als heute.
    Damals konnte ich bei einem Fehlschlag einfach zum Platz nebenan gehen und das Problem lösen, heute ist ein Fehlschlag einfach das Ende
  • Die Remote-Arbeit während Corona war keine echte Remote-Arbeit. Es war Isolation, und weder Kultur noch Prozesse waren darauf vorbereitet.
    Deshalb haben die Leute ihre Einsamkeit der Remote-Arbeit angelastet
  • Ich denke, die Ursache des Wandels liegt weniger in der Demografie als in Veränderungen im Charakter. Früher gab es mehr „seltsame Kinder“, und sie hatten keine Angst zu fragen.
    Heute gibt es mehr sozial angepasste Menschen, die mit asynchroner Kommunikation schlechter zurechtkommen
  • Einen Bug per Chat zu beheben ist nicht dasselbe wie „dieselbe Luft zu atmen“.
    Die Dichte beim Lesen nonverbaler Signale ist geringer, deshalb gehen soziale Hinweise verloren
• Obwohl wir in derselben SaaS-Branche sind, fühlt es sich an, als lebten wir in völlig verschiedenen Welten.
  Viele Entwickler folgen eher Karrierepfaden als Interesse.
  SQL habe ich dreimal neu gelernt. Technologien verändern sich ständig, deshalb kann man sich nicht alles merken.
  Wichtig ist nicht die Syntax, sondern die Fähigkeit, Probleme zu lösen und zusammenzuarbeiten.
  Ich glaube nicht, dass KI das leicht ersetzen kann
• 95 % des Codes, den ich geschrieben habe, hatten 0 % Test-Coverage. Das war in mehreren Ländern und mehreren Firmen so. Ich frage mich, ob das nur bei mir so war
  • Automatisierte Tests sind bei wiederholter Entwicklung ein Werkzeug, das Vertrauen gibt. Wenn man das einmal gelernt hat, will man nicht mehr zurück
  • Bei mir war es ähnlich, aber jetzt versuche ich es zu ändern. In ein Projekt später noch Tests einzubauen, wenn es bisher keine gab, ist wirklich schwer
  • Tests werden teilweise überschätzt. Sie vermitteln manchmal ein falsches Gefühl von Sicherheit. In vielen Fällen eignet sich schon die Sprache selbst nicht besonders gut für Tests
• Die Atmosphäre von Menschen, die um einen herum arbeiten, fördert die Konzentration.
  Es gibt einen ansteckenden Effekt von Fokus. Ein gemeinsamer Arbeitsraum steigert die Produktivität
  • Ich bin auch so ein Typ. Aber meine Firma zwingt uns eine „Clean-Desk-Policy“ auf, und das ist unangenehm. Ich brauche eine personalisierte Umgebung
  • In lebhaften Cafés spüre ich einen ähnlichen Effekt. Die Produktivität anderer spornt mich an
  • Das ähnelt dem „Body Doubling“ bei ADHS
  • Ich arbeite auch lieber im Büro, aber ein Raum mit Tür ist für mich unverzichtbar.
    Eine Tür ist das beste Werkzeug, um Zusammenarbeit und Konzentration zu steuern.
    Eine physische Tür ist ein viel klareres Signal als ein Online-Status wie „away“
  • Aber nicht alle arbeiten in so einer Umgebung gut.
    Für die Konzentration einzelner andere Menschen zwangsweise ins Büro zu holen, ist unmenschlich
• Dieser Text ist mutig. Aber er zeigt auch gut das Problem, persönliche Erfahrungen zu verallgemeinern.
  Nicht Remote-Arbeit ist schlecht, sondern vielleicht nur die Erfahrung, in einer Firma mit schlechten Unterstützungsstrukturen gearbeitet zu haben
• Der Autor ist zu streng mit sich selbst. Zugeben zu können, etwas nicht zu wissen, ist befreiend.
  Ich sage auch oft „Ich weiß es nicht“. Das ist ein Merkmal von Menschen mit hoher EQ
  • Mein Vorgesetzter mochte es, wenn ich sagte: „Ich weiß es nicht.“ Ehrlichkeit schafft Vertrauen
  • Im Job ist das okay, aber online ist es wegen Sorgen um den eigenen Ruf schwer, „Ich weiß es nicht“ zu sagen
  • Wenn man in einem Bewerbungsgespräch nach git rebase fragt, ist die tatsächliche Fähigkeit zur Anwendung wichtiger als technische Details
• Mir gefiel die Ehrlichkeit des Autors. Ich hatte eine ähnliche Erfahrung.
  Beim Live-Coding in Kotlin fiel mir plötzlich die switch-Syntax nicht ein, und das war mir peinlich.
  Da wurde mir klar, dass man selbst eine Sprache, die man täglich benutzt, schnell wieder vergessen kann
  • Ich schaue die switch-Syntax auch jedes Mal nach. Wenn man sie nicht oft benutzt, ist es ganz normal, sie zu vergessen
  • Wenn es mehr ältere Entwickler gibt, werden wir mit solchen „Momenten des Vergessens“ vielleicht nachsichtiger umgehen
  • Jeder macht Fehler. Sogar Vorgesetzte vergessen manchmal die Tastenkombination zum Einfügen
  • Wenn man etwas nicht oft benutzt, verkümmert die Fertigkeit schnell, aber wenn man es wieder benutzt, ist sie auch schnell wieder da.
    Konzepte bleiben lange erhalten, aber Syntaxdetails verschwinden schnell
• Anfangs dachte ich, der Text würde vom Verschwinden der Entwickler durch KI handeln.
  Tatsächlich ist aber schon die Atmosphäre so, dass es schwer ist, diese Angst überhaupt auszusprechen.
  Ich schreibe auch gern Code mit Claude, habe aber gleichzeitig Angst.
  Wenn wir die Generation sind, die das Wesen der kommenden Veränderung am besten versteht, dann sollten wir darüber sprechen
  • Der von Claude erzeugte Code ist nicht unbedingt besser als von Menschen geschriebener. Er erhöht nur die Produktionsgeschwindigkeit.
    Das Problem ist, dass er vielleicht nur die Produktivität von Leuten ohne echte Fähigkeiten erhöht
  • In den nächsten Jahren werden wir wohl Teamleiter von KI-Agenten bleiben.
    Wenn Unternehmen aber anfangen, KI in Managementrollen einzusetzen, bleibt für menschliche Entwickler weniger Platz.
    Man sollte sich schon jetzt auf Rollen wie KI-Effizienzberater vorbereiten
  • Ich werde einfach mit KI zusammenarbeiten oder etwas anderes Interessantes machen. Programmieren ist nicht alles
  • Eine Firma mit einer „AI-Doomer“-Policy ist eine toxische Unternehmenskultur. Da sollte man sofort nach einem neuen Job suchen