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