Software-Essays, die mich geprägt haben

 (refactoringenglish.com)
74 Punkte von GN⁺ 2025-10-02 | 3 Kommentare | Auf WhatsApp teilen
  • Obwohl ich in 20 Jahren Tausende von Software-Blogbeiträgen gelesen habe, haben nur wenige Essays meine Denkweise grundlegend verändert; vorgestellt werden 10 zentrale Essays, vom „Joel Test“ von Joel Spolsky bis zu Julia Evans’ Plädoyer für pures JavaScript
  • Joel Spolskys „Joel Test“ stellt 12 Fragen, um zu bewerten, ob ein Arbeitgeber Entwickler respektiert, und prüft anhand von Quellcodeverwaltung, täglichen Builds und der Priorisierung von Bugfixes, ob Zeit und Konzentration der Entwickler Vorrang haben
  • Alexis Kings „Parse, don't validate“ führt eine Technik ein, bei der Daten bei der Validierung in neue Typen umgewandelt werden, und zeigt, dass Typsysteme zur Verbesserung von Anwendungssicherheit und Zuverlässigkeit beitragen können
  • Fred Brooks’ „No Silver Bullet“ unterscheidet Softwarearbeit in wesentliche und zufällige Komplexität und argumentiert, dass eine Verzehnfachung der Produktivität durch bessere Tools und Hardware unmöglich sei, auch wenn KI diese Theorie ins Wanken bringt
  • Julia Evans’ Essay über pures JavaScript führte zu der Einsicht, dass ES2018 JavaScript allein ausreicht, und seit 2020 wurden deshalb in kein Projekt mehr JavaScript-Frameworks oder Build-Schritte integriert

Joel Spolskys „Joel Test“ (2000)

  • Joel Spolsky ist einer der besten Software-Blogger überhaupt, und seine Essays haben den Ansatz des Autors zur Softwareentwicklung stark geprägt
  • Der „Joel Test“ ist ein Satz aus 12 Fragen, mit dem sich bewerten lässt, wie gut ein Arbeitgeber in ein Software-Team investiert

  • Liste der 12 Fragen

    • Wird Quellcodeverwaltung verwendet?
    • Lässt sich in einem Schritt builden?
    • Werden tägliche Builds durchgeführt?
    • Gibt es eine Bug-Datenbank?
    • Werden Bugs behoben, bevor neuer Code geschrieben wird?
    • Gibt es einen aktuellen Zeitplan?
    • Gibt es Spezifikationen?
    • Haben Programmierer eine ruhige Arbeitsumgebung?
    • Werden die besten Werkzeuge, die man für Geld kaufen kann, verwendet?
    • Gibt es Tester?
    • Müssen neue Kandidaten im Vorstellungsgespräch Code schreiben?
    • Werden Flur-Usability-Tests durchgeführt?

  • Kernaussage

    • Einige Fragen sind heute veraltet, aber nicht die Fragen selbst sind entscheidend, sondern der Meta-Punkt hinter den Fragen
    • Was Joel eigentlich fragt: Werden Entwickler respektiert?
    • Alle Fragen prüfen, ob ein Arbeitgeber Zeit und Konzentration der Entwickler höher bewertet als billige Büroräume und kurzfristige Deadlines
    • Der Text erschien auf dem Höhepunkt des Dotcom-Booms, als erfahrene Entwickler wertvolle Ressourcen waren, auch wenn das nicht allen klar war
    • Joels Blog stellte Programmierer stets als seltene und sensible Genies dar, die Arbeitgeber finden und wertschätzen sollten
    • Der Autor hat während seiner gesamten Laufbahn nach Arbeitgebern gesucht, die beim Joel Test hoch punkten, und ist Joel dankbar für diese Orientierung

Alexis Kings „Parse, don't validate“ (2019)

  • Obwohl es ein Essay über die Nutzung des Haskell-Typsystems ist, hat er die Sicht auf Software grundlegend verändert, auch wenn man sich weder für Typsysteme noch für Haskell interessiert
  • Alexis’ Technik lässt sich in jeder Sprache mit statischer Typisierung einsetzen, etwa in Go, C++ oder Rust

  • Zentrales Konzept

    • Jedes Mal, wenn Daten validiert werden, sollten sie in einen neuen Typ umgewandelt werden
    • Beispiel: Wenn ein Benutzername auf maximal 20 alphanumerische Zeichen begrenzt sein soll, wäre eine naive Lösung eine Funktion validateUsername(username string) error

  • Das Problem

    • Der Code ist standardmäßig unsicher
    • Da jeder eingehende Benutzername validiert werden muss, entsteht leicht versehentlich ein Codepfad, der einen Benutzernamen ohne Validierung verarbeitet
    • Wenn ein böswilliger Nutzer einen solchen Fehler findet, kann er bösartigen Code in das Benutzernamenfeld einschleusen oder es mit Milliarden Zeichen füllen und so Server-Ressourcen erschöpfen

  • Alexis’ Lösung

    • Verwendung einer Funktion parseUsername(raw string) (Username, error)
    • Im Rest der Codebasis wird statt eines string namens „username“ der benutzerdefinierte Typ Username verwendet
    • Die einzige Funktion, die Username erzeugen kann, ist parseUsername; sie wendet die Validierungsregeln an, bevor sie eine Username-Instanz zurückgibt
    • Wenn eine Username-Instanz vorliegt, muss sie einen gültigen Benutzernamen enthalten
    • Nicht vertrauenswürdige Eingaben sind immer string, daher kann man kein string an eine Funktion übergeben, die Username erwartet

  • Wirkung

    • Vor diesem Essay dachte der Autor, Typsysteme seien eine nette Spielerei, mit der Sprach-Nerds sich ablenken
    • „Parse, don't validate“ hat die Augen dafür geöffnet, wie wertvoll Compiler-Funktionen für die Verbesserung von Anwendungssicherheit und Zuverlässigkeit sind

Fred Brooks’ „No Silver Bullet“ (1986)

  • An der Universität wurde Fred Brooks’ The Mythical Man-Month gelesen
  • Eine Sammlung von Essays über Software Engineering, basierend auf seinen Erfahrungen bei der Leitung des IBM-OS/360-Projekts

  • Wesentliche und zufällige Komplexität

    • Wesentliche Komplexität: Arbeit, die unabhängig von Tools und Hardware zwingend getan werden muss
      • Beispiel: In einer Software zur Berechnung von Vertriebsboni die Bonusformel definieren und alle Edge Cases abdecken
      • Das ist dieselbe Aufgabe, egal ob auf einem Supercomputer für $5B oder einem Mikrocontroller für $1
    • Zufällige Komplexität: alles andere
      • Mit Memory Leaks umgehen, auf das Kompilieren von Code warten, herausfinden, wie man eine Third-Party-Library verwendet
      • Je besser die Tools und die Hardware-Ressourcen, desto weniger Zeit geht für zufällige Komplexität verloren

  • Brooks’ Schlussfolgerung

    • Fortschritte bei Tools oder Hardware können keine Verzehnfachung der Entwicklerproduktivität bewirken
    • Selbst wenn sich alle zufälligen Tätigkeiten auf null Zeit reduzieren ließen, wäre eine solche Skalierung unmöglich, sofern sie nicht mehr als 9/10 des Gesamtaufwands ausmachen

  • Anwendungsbeispiele

    • Während der gesamten Laufbahn wurde immer wieder versucht, Programmierer aus der Softwareentwicklung zu entfernen
    • No-Code-Plattformen sorgten für Hype, indem sie Nicht-Programmierern die volle Macht erfahrener Webentwickler versprachen
    • Brooks’ Essay beruhigte immer wieder mit der Erkenntnis, dass die neuesten Buzzword-Plattformen Entwickler nicht ersetzen können
    • Solche Plattformen konzentrieren sich auf zufällige, nicht auf wesentliche Komplexität
    • Selbst wenn eine Plattform aus einer Funktionsspezifikation auf magische Weise lauffähigen Code erzeugen könnte, bräuchte es immer noch jemanden, der die Spezifikation schreibt

  • Einfluss von KI

    • Moderne KI wirft einen Schraubenschlüssel in Brooks’ Theorie
    • KI verringert tatsächlich wesentliche Komplexität
    • Wenn man der KI unvollständige oder widersprüchliche Spezifikationen gibt, füllt sie Lücken, indem sie sich an ähnlichen Spezifikationen orientiert
    • Selbst wenn KI bekannte Formen des Programmierens verdrängt, gibt Brooks’ Essay Hoffnung, dass am Ende auf irgendeiner Abstraktionsebene immer noch jemand nötig ist, der die wesentliche Komplexität steuert

Joel Spolskys „Choices“ (2000)

  • Es war schwer, nur einen Lieblingsessay von Joel Spolsky auszuwählen, daher wurden zwei gewählt
  • „Choices“ handelt von der Gestaltung von Benutzeroberflächen und den subtilen Kosten, die es hat, Nutzern Entscheidungsfreiheit zu geben

  • Kernaussage

    • Jede Option, die man anbietet, verlangt vom Nutzer eine Entscheidung
    • Das bedeutet, dass der Nutzer über etwas nachdenken und eine Entscheidung treffen muss
    • Das ist nicht zwangsläufig schlecht, aber im Allgemeinen sollte man versuchen, die Zahl der Entscheidungen, die Menschen treffen müssen, zu minimieren

  • Beispiel Windows 98

    • Joel zeigt einen absurden Dialog aus Windows 98, der bei der Suche in Hilfedokumenten erscheint
    • Der Dialog machte Joel aus folgenden Gründen wütend:
      • Er unterbricht den Nutzer, obwohl dieser gerade Hilfe sucht
      • Er verlangt eine uninformierte Entscheidung zur Datenbankoptimierung
      • Windows weicht der Entscheidung aus und schiebt sie dem Nutzer zu

  • Anwendungsbereich

    • Joels Essay fokussiert sich auf grafische Benutzeroberflächen, doch der Autor berücksichtigt ihn überall dort, wo Menschen mit Code in Berührung kommen, einschließlich der Kommandozeile oder anderer Entwickler, die geschriebene Funktionen aufrufen
    • Kann man im Namen der Nutzer hilfreiche Entscheidungen treffen und ihnen zugleich Kontrolle über das geben, was ihnen wichtig ist?
    • Joels Essay hat unzählige Male davor bewahrt, Entscheidungen, die ich selbst treffen könnte, an Nutzer weiterzureichen

Raymond Chens „Application compatibility layers are there for the customer, not for the program“ (2010)

  • Raymond Chen ist einer der Entwickler mit der längsten Zugehörigkeit zum Microsoft-Windows-Team
  • Sein Blog enthält Tausende nützliche und unterhaltsame Geschichten über die Geschichte der Windows-Programmierung

  • Beispiel einer Kundenanfrage

    • Kundenanfrage zum Windows-Vista-Kompatibilitätsmodus:
      • Ein für Windows XP und Windows Server 2003 entwickeltes Programm hat unter Windows Vista Schwierigkeiten
      • Wenn es auf den Windows-XP-Kompatibilitätsmodus gesetzt wird, funktioniert es unter Vista gut
      • Gefragt wurde, welche Änderungen am Installer nötig sind, damit es unter Vista automatisch im XP-Kompatibilitätsmodus ausgeführt wird

  • Raymonds Analogie

    • „Normalerweise werfe ich Müll auf den Gehweg vor dem Zoogeschäft, und jeden Morgen, wenn das Geschäft öffnet, fegt jemand den Müll auf und wirft ihn in den Mülleimer. Aber sonntags hat das Zoogeschäft nicht geöffnet, also bleibt der Müll sonntags einfach dort liegen. Wie kann ich dafür sorgen, dass das Zoogeschäft auch sonntags öffnet?“

  • Die Lehre

    • Die Analogie ist so lustig, dass mir erst jetzt aufgefallen ist, dass Raymond Unrecht hatte
    • Er verspottet die Sünde von Entwicklern, die erwarten, dass Windows ihre App nach einem einzelnen Release nicht kaputtmacht
    • Ich stimme den Details nicht zu, aber Raymonds Texte sind so unterhaltsam und scharf, dass man über die Mängel hinwegsehen kann
    • Eine großartige Lektion über die Beeinflussung von Nutzerverhalten:
      • Wenn du Nutzer dazu bringen willst, etwas zu tun, das dir hilft, musst du aus ihrer Perspektive sorgfältig über den Weg des geringsten Widerstands nachdenken
      • Wenn du zeigst, dass das Müllabladen auf dem Gehweg das Problem vollständig löst, werden sie es weiter tun

Erik Kueflers „Don’t Put Logic in Tests“ (2014)

  • Ich mochte Unit-Tests schon immer und war sehr stolz auf meinen Testcode
  • Dieser Essay tauchte wie aus dem Nichts auf und schockierte mich, indem er enthüllte, dass ich meine ganze Karriere über schreckliche Tests geschrieben hatte

  • Beispiel für einen problematischen Test

    @Test public void shouldNavigateToPhotosPage() {  
  String baseUrl = "http://plus.google.com/";;  
  Navigator nav = new Navigator(baseUrl);  
  nav.goToPhotosPage();  
  assertEquals(baseUrl + "/u/0/photos", nav.getCurrentUrl());  
}

  • Erkannte Probleme

    • Als ich den Essay zum ersten Mal las, dachte ich: „Genau so schreibe ich Unit-Tests!“
    • Warum die Zeichenkette http://plus.google.com/ an zwei Stellen duplizieren? Wie im Produktionscode sollte man eine Single Source of Truth schaffen
    • Ich habe in Tests immer Helper-Funktionen, Variablen und Schleifen ergänzt, um Duplikate zu entfernen
    • Das Problem ist, dass dieser Ansatz subtile Bugs verbirgt: Tatsächlich wird http://plus.google.com//u/0/photos geprüft (mit zwei Schrägstrichen)

  • Erkenntnis

    • Eriks Essay zeigt, dass man Testcode nicht wie Produktionscode behandeln sollte
    • Beides hat völlig unterschiedliche Ziele und Randbedingungen
    • Guter Testcode sollte vor allem klar sein
    • Testcode hat keinen eigenen Testcode, daher ist die einzige Möglichkeit, seine Korrektheit zu prüfen, die Inspektion
    • Für den Leser muss blendend offensichtlich sein, welches Verhalten der Test prüft
    • Um dieses Ziel zu erreichen, darf man Duplikation in Kauf nehmen, um Komplexität zu verringern

Julia Evans’ „A little bit of plain Javascript can do a lot“ (2020)

  • Als Softwareentwickler bin ich beschämend spät ins Web eingestiegen
  • In den ersten zehn Jahren meiner Karriere schrieb ich nur Code für Desktop-Apps und Backend-Server
  • Bis 2017 habe ich mich nicht um HTML oder JavaScript gekümmert

  • Missverständnisse über Frameworks

    • Als ich ernsthaft begann, Frontend-Entwicklung zu lernen, hatte ich den Eindruck, JavaScript sei eine in zehn Tagen zusammengeschusterte chaotische Sprache, die sich in jedem Browser stark unterschiedlich verhält
    • Um Web-Apps zu schreiben, brauche man etwas Modernes und Elegantes, das einen vor allem Galligen und Fehlerhaften an JavaScript schützt
    • Ich probierte populäre Web-Frameworks wie Angular, React und Vue aus
    • Ich lernte Vue ausreichend gut, verbrachte aber immer noch enorm viel Zeit mit Abhängigkeitsproblemen und Framework-Fallstricken
    • Selbst nach all dem, was diese Frontend-Frameworks zur Reparatur von JavaScript getan hatten, war Webprogrammierung immer noch furchtbar

  • Die Erkenntnis durch Julias Essay

    • Mir wurde klar, dass ich so überzeugt davon war, dass JavaScript repariert werden müsse, dass ich ihm nie eine Chance gegeben hatte
    • Ich arbeitete an einem TinyPilot-Prototyp und plante, das Webinterface mit Vue umzusetzen
    • Julias Essay inspirierte mich dazu zu sehen, wie weit man mit reinem JavaScript kommen kann
    • Ohne Framework, Wrapper-Bibliothek, Build-Step oder Node.js, einfach nur mit normalem JavaScript (ES2018)
    • Ich erwartete ständig, auf Probleme zu stoßen, die einen Wechsel zu einem Framework oder Builder nötig machen würden, aber das passierte nie
    • Es gab ein paar Fallstricke rund um WebComponents, aber verglichen mit den Schmerzen, die ich mit Vue und Angular hatte, war das nichts

  • Die Freiheit ohne Frameworks

    • Ich liebe es, frei von Frameworks zu sein
    • Wenn es einen Runtime-Fehler gibt, ist der Stack Trace nicht der Fiebertraum von minimiertem, transformiertem und tree-shaken Code
    • Ich debugge meinen Code so, wie ich ihn geschrieben habe
    • Meine Vorurteile gegenüber JavaScript waren falsch
    • Modernes JavaScript ist ziemlich gut und hat viele Ideen aus Wrapper-Bibliotheken übernommen, sodass man Wrapper inzwischen nicht mehr braucht
    • Die Browser haben sich zusammengerissen, um konsistentes Verhalten über Plattformen und Geräte hinweg sicherzustellen
    • Seit 2020 habe ich in kein neues Projekt mehr ein JavaScript-Framework oder einen Build-Step integriert und nie zurückgeblickt
    • Mit reinem JavaScript bekommt man 90 % der Vorteile von Frameworks bei 5 % der Kopfschmerzen

Dan McKinleys „Choose Boring Technology“ (2015)

  • Es ist ein seltsamer Essay für diese Liste, weil ich ihn tatsächlich nie gelesen habe
  • Leute zitierten diesen Essay, und sobald ich die Idee verstanden hatte, erschien sie mir so intuitiv, dass ich keinen Bedarf mehr sah, ihn zu lesen

  • Die Kernidee

    • Wenn man ein neues Projekt beginnt, ist die Versuchung groß, viel diskutierte Spitzentechnologie zu verwenden
    • Google kündigt eine neue Datenbank an, die bis in den Exabyte-Bereich skaliert, 40 % schneller als Postgres ist und 20 % weniger kostet
    • Wenn diese sexy neue Alternative direkt vor dir steht, wirkt es dumm, Postgres zu verwenden
    • In Wirklichkeit haben neue Technologien Bugs und Schwächen, die nur noch nicht offensichtlich sind
    • Wenn man auf sie stößt, steht man ratlos da
    • Postgres hat Probleme, aber nach 30 Jahren Praxiserfahrung gibt es erprobte Lösungen für praktisch jedes Problem, dem man wahrscheinlich begegnet

  • Das Konzept der Innovationstoken

    • Dan räumt ein, dass man manchmal neue Technologien einsetzen muss, aber nur strategisch und in begrenzter Zahl
    • Jedes Unternehmen bekommt drei „Innovationstoken“ zum Ausgeben
    • Wenn man die schicke neue Datenbank will, muss man einen dieser Token ausgeben
    • Dans Essay greift auf natürliche Weise Julias Essay auf
    • Ich wünschte, ich hätte einen von beiden gelesen, bevor ich all diese Zeit mit Frontend-Frameworks verschwendet habe

Terence Edens „I’ve locked myself out of my digital life“ (2022)

  • Terence Eden ist ein unterhaltsamer und vielseitiger Tech-Blogger
  • Er schreibt jede Woche mehrere neue Beiträge, aber den größten Einfluss hatte „Ich habe mich aus meinem digitalen Leben ausgesperrt“

  • Katastrophenszenario

    • Simulation, was passieren würde, wenn ein Blitz in Terences Haus einschlägt und seinen gesamten Besitz zerstört
    • Alle Passwörter für alles im Passwort-Manager gespeichert
    • Wenn alle Geräte zerstört werden, ist der Zugriff auf den Passwort-Manager nicht mehr möglich
    • Warum das nicht durch Hardware-Passkeys ersetzt werden kann: weil auch diese sich im Haus befanden

  • Erkenntnis

    • Der Autor hatte das Gefühl, in Bezug auf Daten ziemlich sicher zu sein, da er alles auf redundanten Laufwerken speichert und Offsite-Backups über zwei Anbieter auf drei Kontinenten hat
    • Terences Text brachte ihn dazu, über viele glaubwürdige Bedrohungen nachzudenken, die alle Geräte gleichzeitig vernichten könnten: Feuer, Überschwemmung, Stromstoß, strafrechtliche Ermittlungen
    • Da alle Daten mit einem Passwort verschlüsselt sind, das sich im Kopf befindet, kommen auch Gedächtnisverlust, Handlungsunfähigkeit und Tod auf die Liste

  • Das Problem mit Online-Diensten

    • Online-Dienste sind schlecht darin, Nutzern bei der Wiederherstellung nach einer Katastrophe zu helfen
    • Nutzung mehrerer Dienste, die davon ausgehen, dass es unmöglich ist, das Telefon zu verlieren, ganz zu schweigen vom E-Mail-Konto und allen digitalen Geräten, die man besitzt

  • Auswirkungen

    • Seit der Lektüre von Terences Essay denkt der Autor stärker darüber nach, welche Dienste und Geräte kritisch sind und wie er sich in dem von Terence beschriebenen Szenario davon erholen könnte
    • Als er seinen nächsten Laptop kaufte, richtete er ihn in der Bibliothek ein, um zu testen, ob er den Zugriff auf den Passwort-Manager und wichtige Konten ohne die Geräte zu Hause wiederherstellen kann
    • Er könnte sich noch immer besser auf digitale Katastrophenvorsorge vorbereiten, aber Terences Text hallt in seinem Kopf nach, jedes Mal wenn er darüber nachdenkt, wie er Geräte und Daten absichert
    • Was würde passieren, wenn plötzlich alles zerstört wäre?

Bonus: Brad Fitzpatricks „parsing user input“ (2009)

  • Technisch gesehen kein Essay, aber ein Zitat aus einem Software-Interview, über das der Autor immer wieder nachdenkt
  • Coders at Work nach Joel Spolskys begeisterter Rezension von 2009 gelesen
  • Eine Sammlung von Interviews mit erfolgreichen Programmierern

  • Brad Fitzpatricks Zitat

    • Brad Fitzpatrick, Gründer von LiveJournal und Memcached, ist einer der Interviewpartner
    • Damals 28 Jahre alt, der jüngste Programmierer im Buch und derjenige mit der derbsten und lustigsten Ausdrucksweise
    • Auf eine Frage zur Ethik des Software Engineerings folgt ein leidenschaftliches Plädoyer für Input-Validierung:
      • „Ich wünschte, alle würden konsequent zulassen, dass man in Kreditkartenformularen Leerzeichen oder Bindestriche eingibt. Computer sind gut darin, so etwas zu entfernen. Sagt mir nicht, wie ich meine Zahlen zu formatieren habe.“

  • Anwendung

    • Jedes Mal, wenn der Autor versucht, eine Telefonnummer in ein Webformular einzufügen, denkt er an dieses Zitat
    • Er beschwert sich darüber, dass Klammern oder Leerzeichen nicht erlaubt sind, oder schlimmer noch, dass die Telefonnummer wegen der Klammern abgeschnitten wird und das Formular sich dann darüber beschwert, dass Klammern nicht erlaubt sind
    • Jedes Mal, wenn er in Software ein Eingabefeld erstellt und über unerwartete Zeichen nachdenkt, hört er Brad Fitzpatrick sagen: „Computer sind gut darin, so etwas zu entfernen.“

Verwandte Beiträge

3 Kommentare

 
shakespeares 2025-10-07

Ohne Geschichte gäbe es kein Heute.
 
GN⁺ 2025-10-02
Hacker-News-Kommentare

  • Nachdem ich den Artikel "I've locked myself out of my digital life" gelesen hatte, hatte ich das Gefühl, dass er eine Sorge gut ausdrückt, die ich schon lange hatte, aber nur schwer beschreiben konnte
    In der analogen Welt könnte ich einen Menschen davon überzeugen, wer ich bin, mich identifizieren und wieder Zugang zu meinem Konto bekommen, aber vor den erbarmungslosen Algorithmen der digitalen Welt nützt alles Bitten nichts, wenn man keine Zugangsdaten hat
    Nicht einmal die Firma meines Passwortmanager-Dienstes hat Zugriff auf meine Passwörter
    Es gibt nicht einmal jemanden, den man überzeugen könnte; nur noch der Code ist das Gesetz
    Ich finde, alle sollten dieses Problem verstehen, bevor sie dafür plädieren, persönliche Kontakte aus sämtlichen Prozessen zu entfernen
    Im Artikel klingt es vielleicht nach einer seltenen Situation, aber bei Naturkatastrophen oder Diebstahl kann so etwas durchaus passieren
    Verwandter Artikel: https://shkspr.mobi/blog/2022/06/ive-locked-myself-out-of-my-digital-life/

    • Ich glaube nicht, dass es tatsächlich viele Menschen gibt, die eine derart extreme Automatisierung oder die Reduktion persönlicher Interaktion befürworten
      Und das ist kein Problem, das nur mit AI zu tun hat; bei regelbasierter Software ist es genauso
      In der Europäischen Union (EU) ist das Recht, jede Entscheidung von einem Menschen anfechten zu lassen, gesetzlich garantiert

  • Grug Brained Developer ist ein Text, der mir immer im Kopf geblieben ist, stand aber nicht auf der Liste
    Wahrscheinlich eher deshalb, weil ich dem Inhalt ohnehin schon zugestimmt habe, also weniger wegen einer gedanklichen Umwälzung als weil er einfach hängen geblieben ist
    Referenz: https://grugbrain.dev/

    • Von all dem gefällt mir besonders die Stelle, dass es das beste Gefühl sei, „den Komplexitätsdämon endlich in korrigiertem Kristall einzusperren“

    • Ich bin zweisprachig und spreche Englisch als zweite Sprache, deshalb sind Texte im grug-brain-Stil ziemlich schwer zu lesen und zu verstehen
      Ich weiß nicht einmal, was das Wort „grug“ bedeuten soll
      Trotzdem lese ich den Blog immer noch mit Vergnügen

  • Ich stimme der Schlussfolgerung zu Fred Brooks' "No Silver Bullet" nicht zu
    Ich stimme auch nicht der jüngeren Behauptung zu, dass AI die wesentliche Komplexität so weit reduziert habe, dass Brooks' These widerlegt sei
    AI kann unvollständige oder widersprüchliche Spezifikationen vielleicht anhand ähnlicher Fälle automatisch ergänzen, aber die wesentliche Komplexität wird dadurch immer noch nicht ausreichend aufgelöst, und ich glaube auch nicht, dass das künftig möglich sein wird
    Meine ausführlichere Analyse dazu steht hier: https://smartmic.bearblog.dev/no-ai-silver-bullet/

    • Danke fürs Lesen und dafür, dass du meinen Artikel geteilt hast
      Wie du in deiner Erläuterung erwähnt hast, stimme ich zu, dass LLMs wesentliche Komplexität nicht vollständig beseitigen können
      Ich denke aber, dass LLMs sie bis zu einem gewissen Grad verringern können
      Als konkretes Beispiel habe ich Claude 4.1 Opus gebeten, eine domänenspezifische Sprache für computergenerierte Bilder zu definieren
      Ich habe nur die Anforderungen übermittelt und die Details bewusst vage gelassen, und das LLM hat daraus eine Spezifikation geschrieben
      In solchen Fällen bin ich sicher, dass das LLM die wesentliche Komplexität reduziert hat
      Ich könnte das zwar selbst in hoher Qualität neu definieren, aber wenn das Ergebnis des LLMs gut genug ist, gibt es weniger Grund, zusätzliche Mühe für Qualitätsverbesserungen aufzuwenden
      Ursprünglich hatte ich das Gefühl, LLMs nicht wirklich zu brauchen, weil ich selbst besser coden kann und daran auch mehr Freude habe, aber nachdem ich sie ausprobiert habe, sehe ich, dass sie einen erheblichen Teil der wesentlichen Komplexität in genau den Bereichen übernehmen, in die ich meine eigene Zeit und Energie nicht stecken muss
      Beispiel: https://kagi.com/assistant/1b8324a2-ae54-4a1b-9c69-51d76fc5c7d1

    • Die Komplexität, die AI reduziert, ist letztlich nur die kognitive Last der Person, die den Code schreibt
      Die von Brooks so genannte „nicht wesentliche Komplexität“ bleibt im Code selbst fast vollständig erhalten
      Dadurch wird diese Last am Ende nur auf die Person verlagert, die den Code lesen muss
      Es ist, als würde man mit einem Exoskelett einen schweren Gegenstand auf ein Regal heben und dann einen Kollegen bitten, ihn schön anzustreichen

  • Das Paper "Parse, don't validate" ist meiner Meinung nach ein klassischer Meisterwerk
    Und mit dem Satz "Don't put logic in tests" tue ich mich eher schwer
    Im Beispiel geht es um ein Problem, das daraus entsteht, dass statt eines URI-Typs ein String verwendet wird, und ich finde, Testcode sollte ebenfalls als Produktionscode betrachtet werden, weil auch er Erfolg oder Misserfolg eines Deployments beeinflusst
    So oder so sind solche Diskussionen auf jeden Fall wertvoll genug, um sie selbst zu prüfen und zu überlegen, ob sie auf die eigene Arbeit anwendbar sind

    • Ich finde auch erstaunlich, wie wenig bekannt "Parse, don't validate" ist
      In meinem Umfeld arbeiten die meisten mit Go, Python oder C++, deshalb scheint das eher nur in der Welt der funktionalen Sprachen bekannt zu sein
      Ich finde die kritische Perspektive auf das Beispiel zu "Don't put logic in tests" berechtigt
      Das Beispiel ließe sich vielleicht durch einen etwas besseren Fall ersetzen, aber der entscheidende Punkt ist, dass selbst simples Zusammenfügen von Strings Tests komplexer machen und dazu führen kann, dass Bugs übersehen werden

    • Mich persönlich spricht die Philosophie an, keine (zu viele) Logik in Tests zu stecken
      Ich habe mehrfach False Positives erlebt, die durch Bugs im Testcode verursacht wurden, und dadurch ein gewisses Misstrauen gegenüber solchen Dingen entwickelt
      Ich finde, man sollte nicht das Bedürfnis haben, „Tests für die Tests“ schreiben zu müssen
      In der Praxis kommt das zwar selten vor, aber in letzter Zeit werden miserable, von LLMs geschriebene Tests immer mehr zum Mainstream, sodass das Problem unabhängig von dieser Philosophie größer wird

  • Ich empfehle Nancy Levesons Untersuchungen und Review-Materialien zum Therac-25-Unfall

  • Mein Lieblingstext in diesem Bereich ist Neil W. Rickerts "The Parable of the Two Programmers"
    Es ist eine Geschichte, die das Leben und die Herausforderungen von Programmierern prägnant zusammenfasst
    https://c00kiemon5ter.github.io/code/philosophy/2011/10/30/Tale-of-two-Programmers.html

    • Ich kenne Neil gut, weil ich über Jahre hinweg im Usenet-Newsgroup comp.ai.philosophy oft mit ihm zu tun hatte
      Ton und Inhalt des Textes sind wirklich ganz typisch für ihn

    • Dieser Text ist wirklich großartig

  • Für mich war dieser Text ein Wendepunkt
    https://stevemcconnell.com/articles/software-quality-at-top-speed/

    McConnell ist hier nicht besonders bekannt

    • Danke fürs Teilen!
      Das ist das erste Mal, dass ich diesen Text lese, aber zu Beginn meiner Karriere hat mich Code Complete stark beeindruckt
      Ich hatte das Buch immer im Regal stehen und dachte selbst nach nur wenigen erneuten Blicken immer wieder: „Das ist wirklich großartig, das muss ich unbedingt noch einmal lesen“
      Ich hatte lange nichts mehr von McConnell gehört und mich gefragt, warum Zeitgenossen wie Kent Beck, Martin Fowler oder Ward Cunningham auch nach dem Rückgang ihrer Popularität seit den 2000ern weitergeschrieben haben, während es um McConnell still geworden war
      Dass er offenbar ganz aus der Softwarebranche ausgestiegen ist und Finanzberater wurde, war auf eine merkwürdige Weise schockierend
      https://raindogllc.com/steve-mcconnell-investment-advisor/

  • Streng genommen ist es vielleicht kein klassischer Software-Essay, aber Gilad Brachas Blogpost "Ban on Imports" hat meine Sicht auf Modulsysteme vollständig verändert
    Er betont, dass import/export im Grunde globalem Zustand gleichkommt und damit alle Probleme des globalen Zustands mit sich bringt
    Seitdem schätze ich das Konzept der Dependency Injection deutlich höher ein
    https://gbracha.blogspot.com/2009/06/ban-on-imports.html

  • Vielleicht lässt es sich nicht streng als Software-Essay einordnen, aber Patrick McKenzies "Don't Call Yourself A Programmer, And Other Career Advice" ist ein wahrer Schatz
    https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/

  • Als jemand, der sich sehr für Programmiersprachen interessiert, ist mir der Text "slumming with basic programmers" stark im Gedächtnis geblieben
    https://prog21.dadgum.com/21.html
 
secret3056 2025-10-02

Dem Parsen von Benutzereingaben kann ich wirklich sehr gut zustimmen.
In welcher Umgebung arbeiten eigentlich so viele Coder, die eine Funktion zur Eingabe alternativer Telefonnummern entwickeln, dass sie solche Angst davor haben, bei einem String zweimal replace() aufzurufen?