Ich führe eine Liste mit jedem Buch, das ich lese. Inzwischen sind es über 130, und die meisten haben Spuren in meiner Arbeit hinterlassen. Hier steht die kurze Version: die Titel, zu denen ich immer wieder zurückkehre, sortiert nach dem Teil meines Denkens, den sie geprägt haben, und die Menschen, deren Ideen dahinterstehen. Ich lese so viel aus einem Grund. Ich unterrichte, und Unterrichten funktioniert nur, wenn du selbst weiterlernst.
Programmieren als kreatives Handwerk, näher an der Malerei als am Bauingenieurwesen. Aus diesem Buch stammt der Name hackers&wizards, und es ist der Grund, warum ich Technologiearbeit menschlich halte, auch wenn immer mehr davon automatisiert wird.
Die Forschung hinter DORA. Zu diesem Buch greife ich, wenn jemand behauptet, Qualität mache Teams langsamer. Das Gegenteil stimmt, und Accelerate hat die Daten, die es belegen.
Newman hat geprägt, wie ich über Systemgrenzen und die Teamstrukturen drumherum denke. Dieses Denken zog sich direkt durch die Architekturarbeit bei Breuninger und BLUME 2000.
Evans hat mir die Sprache gegeben, um ein System am Business auszurichten, dem es dient. Die meisten Architekturdebatten, die ich erlebt habe, drehen sich eigentlich darum, wo eine Domänengrenze liegen sollte.
Farley versteht Softwareentwicklung als experimentelle Praxis: Feedbackschleifen bauen, kleine Experimente fahren, die Ergebnisse entscheiden lassen. Das Buch hat mich mehr vom Bauchgefühl weggebracht als jedes einzelne Pattern.
Eine klare Anleitung, wie du Code so organisierst, dass er sich später ändern lässt. Ich stimme nicht jeder Zeile zu, aber die Kernideen tauchen in jedem Architektur-Review auf, das ich mache.
Das Buch, das mein Denken über Monitoring, Incidents und Betrieb zusammengebracht hat. Zuverlässigkeit ist ein Feature, und hier hat es bei mir Klick gemacht.
Hohpe schreibt über Plattformen und Enterprise-Architektur, ohne den Faden zu verlieren. Hilfreich, sobald eine Engineering-Organisation so groß wird, dass die Plattform zum Produkt wird.
Das klarste Buch über Führung, das ich kenne. Marquet hat ein Atom-U-Boot geführt, indem er Kontrolle abgegeben hat, statt Befehle zu erteilen. Seitdem führe ich anders: Das Ziel ist nicht, der Klügste im Raum zu sein.
Der Nachfolger, und er hat geschärft, wie ich mit Teams spreche. Kleine Änderungen daran, wie du eine Frage formulierst, ändern, wer sich traut mitzudenken.
Ein kurzes, scharfes Modell dafür, wie Teams scheitern, beginnend mit fehlendem Vertrauen. Ich habe jede Stufe von Lencionis Pyramide in echten Teams erlebt.
Coyle schaut sich an, was Hochleistungsgruppen tatsächlich tun, und das meiste davon ist klein und unspektakulär. Passt gut als Begleitlektüre zu Lencioni.
Ein praktischer Blick auf Teamstruktur und Cognitive Load. Das Buch hat mir Begriffe für Entscheidungen gegeben, die ich vorher aus dem Bauch getroffen hatte.
Kahneman kartiert die Verzerrungen, mit denen Menschen entscheiden. Wenn du Systeme baust, die andere benutzen, ist das Pflichtlektüre.
Tegmark fragt, was aus dem Sinn menschlichen Lebens wird, wenn Maschinen in fast allem sehr gut werden. Das Zoo-Szenario geht mir seit Jahren nicht aus dem Kopf.
O'Neil zeigt, wie Algorithmen unbemerkt Vorurteile festschreiben und im großen Maßstab Schaden anrichten. Ein nötiges Gegengewicht zu jedem Optimismus in Sachen Automatisierung.
Russells Darstellung des AI-Alignment-Problems, geschrieben von jemandem, der das Feld mit aufgebaut hat. Deshalb denke ich AI als etwas, das Menschen unterstützt, statt sie zu ersetzen.
Das Buch, das mir beigebracht hat, nach Feedbackschleifen zu suchen statt nach einzelnen Ursachen. Seitdem lese ich Code und Organisationen anders.
Ein neueres Buch, das Systemdenken in den Engineering-Alltag holt. Praktisch, wo Meadows die Grundlagen legt.
Ein visueller Weg, abzubilden, wie ein Unternehmen tatsächlich Geld verdient. Hilfreich, um Architekturentscheidungen damit zu verbinden, wo der Wert entsteht.
Senge über die lernende Organisation. Das Buch prägt, wie ich darüber denke, wie Teams Wissen aufbauen und weitergeben.
Duke, früher Pokerspielerin, darüber, wie du unter Unsicherheit gut entscheidest. Duke trennt eine gute Entscheidung von einem guten Ergebnis, und das ist schwerer, als es klingt.
Snowdens Framework, um das Einfache, das Komplizierte und das Komplexe auseinanderzuhalten und in jedem Fall anders zu handeln. Es bewahrt mich davor, die falsche Art von Lösung anzuwenden.
Das Beste, was ich über die unbeabsichtigten Folgen von Fortschritt gelesen habe. Wenn mich eine neue Technologie begeistert, ist Liu die Stimme, die nach den Effekten zweiter und dritter Ordnung fragt.
Das Buch, das die Vorstellungswelt des Cyberpunk geschaffen hat. Gibson hat die Form des vernetzten Lebens Jahrzehnte im Voraus gesehen.
Asimov über die Frage, ob sich der Weg einer ganzen Zivilisation vorhersagen und steuern lässt. Das knüpft an mein Interesse an, Systeme zu messen, und an die Grenzen dieser Idee.
Jede Zeile ist die Idee, die ich mir bei ihnen geliehen habe, in meinen Worten, kein Zitat.
Software engineering is an experimental practice.
David Farley
Farley hat mich dazu gebracht, Softwareentwicklung wie Wissenschaft zu behandeln. Nicht die Sorte mit Laborkittel, sondern die, bei der du Feedbackschleifen baust, kleine Experimente fährst und dir von den Ergebnissen sagen lässt, was als Nächstes kommt. Dieser Wechsel hat meine Arbeit stärker verändert als jedes einzelne Architektur-Pattern.
As independent as possible, as integrated as necessary.
Stefan Tilkov
Von Tilkov habe ich Self-Contained Systems, das Pattern zwischen Microservice-Wildwuchs und Monolith. Sein leiserer Punkt: Grenzen folgen den Business Capabilities, nicht dem Organigramm und nicht dem Datenbankschema. Er ist 2024 gestorben. Ich höre seine Sicht bis heute, jedes Mal, wenn ein Team darüber streitet, wo eine Grenze verlaufen soll.
Refactoring is how good software gets built, not cleanup work.
Martin Fowler
Von Fowler habe ich gelernt, dass gute Architektur keine perfekte Zeichnung vom ersten Tag ist. Gute Architektur ist ein System, das sich ändern kann, während du das Problem besser verstehst. Der Feind war nie die Veränderung. Es war die Unfähigkeit, sich zu verändern.
Make it work, make it right, make it fast.
Kent Beck
Von Beck habe ich gelernt, dass die mutigste technische Entscheidung meistens die einfachste ist. Bei Test-driven Development ging es mir nie wirklich um Tests. Es geht darum, Code zu schreiben, den andere lesen und ändern können.
Quality enables speed.
Nicole Forsgren
Forsgren hat Zahlen an etwas geschrieben, worüber unsere Branche früher nach Gefühl gestritten hat. Die DORA-Forschung hat Delivery messbar gemacht, und die DORA-Metriken wurden meine gemeinsame Sprache mit dem Management.
Give control away instead of giving orders.
L. David Marquet
Marquet hat ein Atom-U-Boot geführt, indem er Kontrolle abgegeben hat, statt Befehle zu erteilen. Seitdem führe ich anders: Das Ziel ist, Bedingungen zu schaffen, unter denen alle anderen bessere Entscheidungen treffen, als ich es könnte.
Happy engineers build better products.
Gene Kim
Kim hat technische Praxis so mit Geschäftsergebnissen verbunden, dass es Entwicklern und Management am selben Tisch endlich einleuchtete. Er hat mir die Worte gegeben, um zu erklären, warum Developer Experience und Customer Experience dasselbe Gespräch sind.
The zoo scenario: people kept comfortable, and quietly without purpose.
Max Tegmark
Tegmark stellt die Fragen, die ich nicht beantworten kann und nicht ignorieren sollte. Sein Werk hat geprägt, wie ich über Effizienz denke. Die spannende Frage ist nicht, wie schnell wir sein können. Sondern wo wir eigentlich ankommen wollen.
System 1 and System 2: fast, automatic thinking and slow, effortful thinking.
Daniel Kahneman
Kahneman hat die Verzerrungen kartiert, mit denen Menschen entscheiden. Wenn Menschen immer wieder falsch wählen, lautet die ehrliche Schlussfolgerung meistens: Das Design ist falsch, nicht die Menschen.
You learn to paint mostly by doing it. Ditto for hacking.
Paul Graham
Grahams Essays begründen, warum Programmieren ein kreatives Handwerk ist. Aus Hackers & Painters stammt der Name hackers&wizards, und deshalb finde ich bis heute, dass Technologiearbeit menschlich bleiben sollte.
Every solution creates new problems.
Liu Cixin
Lius Trisolaris-Trilogie ist das Beste, was ich über die unbeabsichtigten Folgen von Fortschritt gelesen habe. Wenn mich eine neue Technologie begeistert, ist Liu die leise Stimme, die nach den Effekten fragt, die ich noch nicht zu Ende gedacht habe.
Wenn ein Buch verändert hat, wie du Software baust oder ein Team führst, erzähl mir davon. Einige meiner liebsten Gespräche beginnen damit, dass mir jemand einen Titel nennt, von dem ich noch nie gehört hatte.