- Senior-Entwickler und Nicht-Entwickler verstehen denselben Satz, dass AI-Agenten Entwickler ersetzen würden, anhand unterschiedlicher Maßstäbe: Stabilität und Marktlernen
- Business-Organisationen wollen schnell releasen, Feedback erhalten und Unsicherheit verringern, während Senior-Entwickler vor wachsender Komplexität warnen, die Systeme beschädigen kann
- Sobald es Kunden gibt, laufen zwei Zyklen gleichzeitig: Markterkundung und Aufrechterhaltung des Service. Die Kernverantwortung von Senior-Entwicklern verschiebt sich dann zu Komplexitätsmanagement
- Überzeugungsarbeit endet nicht damit zu sagen, dass „Komplexität das Problem ist“, sondern gelingt nur, wenn man dem Bedürfnis nach Tempo mit schnelleren Experimenten entgegenkommt, etwa mit Google Forms oder einem bestehenden UI-Button
- AI erhöht das Auslieferungstempo, kann aber Verständlichkeit, Änderbarkeit und Debuggbarkeit verschlechtern und übernimmt keine Verantwortung; deshalb können Senior-Entwickler Speed und Scale voneinander trennen
Warum derselbe Satz nach unterschiedlichen Maßstäben verstanden wird
- Senior-Entwickler und Nicht-Entwickler verstehen denselben Satz – „AI-Agenten sind die Zukunft der Softwareentwicklung, und Entwickler werden nicht mehr gebraucht“ – auf unterschiedliche Weise
- Im Copywriting muss eine Botschaft auf das Publikum zugeschnitten sein; derselbe Satz bekommt je nach Zuhörerschaft eine andere Bedeutung
- Dass die Intuition von Senior-Entwicklern von AI-Optimismus abweicht, liegt daran, dass sich die Problemdefinition je nach Fokus der Arbeit unterscheidet: Marktlernen oder Service-Stabilität
Wovor Senior-Entwickler warnen
- Unter Senior-Entwicklern gibt es den Typus, der etwas einführen möchte, gestützt auf neue Tools, Vorgehensweisen anderer Unternehmen oder Best Practices von Hacker News
- Die höher geschätzten Senior-Entwickler fragen zuerst: „Brauchen wir das wirklich?“, „Was passiert, wenn wir es nicht tun?“ und „Können wir es jetzt aushalten und später noch einmal darauf zurückkommen, wenn es wichtiger wird?“
- Dieser Typ versucht, Entwicklung so weit wie möglich zu vermeiden, zu reduzieren und wiederzuverwenden
- In der professionellen Softwareentwicklung ist das, wovor Senior-Entwickler am stärksten warnen, Komplexität
- Sonderfälle,
if-Abfragen, neue Datenbanktabellen und neue Komponenten erhöhen jeweils die Komplexität des Systems - Entwickler, die Verantwortung für ein laufendes System tragen, beginnen am Ende zwangsläufig, wachsende Komplexität zu fürchten
- Selbst Senior-Entwickler, die besonders gut in neuartigen und kreativen Designs sind, werden vorsichtig gegenüber Komplexität, wenn sie ein laufendes System verantworten
Wovor Business-Organisationen warnen
- Marketer, Vertriebsmitarbeiter, Produktmanager und CEOs befinden sich in einem Zyklus, in dem sie etwas auf den Markt bringen, Feedback erhalten und lernen, ob es wertvoll ist
- Das Ziel dieses Zyklus ist Lernen, und die größte Bedrohung ist Unsicherheit
- Da keine Strategie Erfolg garantieren kann, wirkt Unsicherheit unerbittlich
- Wenn Marketing- und Vertriebsanreize, das Gehalt von Gründern und die Daten der Produktmanager mit Zeitdruck zusammenkommen, fühlt es sich so an, als sei der einzige Weg, Unsicherheit vor einer Deadline zu verringern, etwas so schnell wie möglich auf den Markt zu bringen
- Je mehr auf den Markt gebracht wird, desto mehr Feedback kommt zurück – und potenziell lässt sich Unsicherheit stärker verringern
- Jedes Unternehmen beginnt in diesem Zyklus, und dieser Zyklus dreht sich um pure Geschwindigkeit
Der zweite Zyklus nach den ersten Kunden
- Sobald Kunden anfangen zu zahlen, entsteht ein zweiter Zyklus, dessen Ziel in Fortbestand und Gewährleistung des Service liegt
- Das System muss weiterlaufen und verständlich, debuggbar, änderbar, lehrbar und stabil sein
- Senior-Entwickler legen Wert auf Stabilität, weil sie die Business-Verantwortung tragen, Kunden weiterhin zu bedienen
- Was all das erneut bedroht, ist Komplexität
- Komplexität macht ein System weniger verständlich, weniger debuggbar, weniger änderbar, schwerer vermittelbar und letztlich weniger stabil
- Steigt die Komplexität, sinkt die Stabilität; Senior-Entwickler können ihrer Verantwortung nicht nachkommen, und Probleme wie ausbleibende Zahlungen können entstehen
- Wenn das Ziel des ersten Zyklus die Verringerung von Unsicherheit ist, dann ist das Ziel des zweiten Zyklus Komplexitätsmanagement
Wo Kommunikation scheitert
- Sobald es Kunden gibt, laufen die zwei Zyklen – Markterkundung und Service-Aufrechterhaltung – gleichzeitig
- Das Business muss Möglichkeiten erkunden und gleichzeitig Kunden bedienen
- Je nachdem, in welchen Zyklus Zeit investiert wird, erscheint dasselbe Problem anders
- Business-Organisationen wollen schneller bauen und releasen, um Unsicherheit zu verringern
- Senior-Entwickler sorgen sich mit jeder zusätzlichen Anforderung um Komplexität, Wartungskosten, Verständlichkeit, nachhaltige Entwicklungsgeschwindigkeit und langfristige Produktivität
- Doch allein mit der Sprache des Komplexitätsmanagements lässt sich das Bedürfnis anderer Abteilungen nach Unsicherheitsreduktion nur schwer erfüllen
- Wer überzeugen will, muss die Lösung des Senior-Entwicklers auch als Lösung für das Problem des Gegenübers formulieren
- Kommunikation scheitert, wenn das Problem aus der Perspektive des Komplexitätsmanagements beschrieben wird, die Lösung aber nicht aus der Perspektive der Unsicherheitsreduktion
Die praktische Stärke von Senior-Entwicklern
- Die nützlichste Fähigkeit von Senior-Entwicklern besteht darin, nichts Unnötiges zu bauen und Gelegenheiten zur Wiederverwendung bereits gebauter Dinge zu erkennen
- Wenn Umfragedaten gesammelt werden müssen, kann man Google Forms verwenden
- Statt eine ganze neue Funktion zu bauen und zu testen, kann man einen Button in die bestehende UI einfügen und sehen, ob Leute darauf klicken
- Bevor ein neuer Analytics-Service eingeführt wird, kann man zuerst nach der wichtigsten Entscheidung fragen, für die Analytics gebraucht wird, und mit einer Entscheidung, einem Diagramm und einer Kennzahl beginnen
- Statt die ganze Geburtstagstorte zu backen, kann man sinngemäß auch einfach eine Kerze in ein Sandwich stecken
- Senior-Entwickler lernen, vorhandene Software so zu nutzen, dass Menschen bekommen, was sie wollen
- Ein kurzer Satz, um das zu vermitteln, lautet: „Can we try something quicker?“
- „quicker“ erkennt an, dass die andere Seite tatsächlich Geschwindigkeit will
- „something“ deutet an, dass es auch andere Wege zum Ziel gibt
- „try“ trägt die Möglichkeit in sich, dass etwas unvollkommen, aber gut genug sein kann
- Dieser Satz erkennt die vom Unternehmen gewünschte Geschwindigkeit der Unsicherheitsreduktion an und gibt Senior-Entwicklern zugleich Raum, ihre Expertise im Reduzieren, Wiederverwenden und möglichst Vermeiden einzusetzen
Der Druck, den AI verändert, und die Verantwortung, die bleibt
- Weil AI in kurzer Zeit sehr viel erzeugen kann, kann die Haltung des Reduzierens, Wiederverwendens und Vermeidens bedeutungslos wirken
- Doch AI kann bislang eine Sache nicht leisten, die Senior-Entwickler tun: Verantwortung übernehmen
- Senior-Entwickler legen Wert auf die Verständlichkeit eines Systems, weil sie Probleme im Ernstfall beheben können müssen
- Verständlichkeit ermöglicht es, ein System intelligent zu skalieren, wenn es wachsen muss, und zahlende Kunden weiter zuverlässig zu bedienen
- AI erhöht die Geschwindigkeit der Markteinführung erheblich, wirkt sich aber auch auf den Stabilitätszyklus aus, für den Senior-Entwickler Verantwortung tragen
- Wenn AI-Agenten, Junior-Entwickler, Nicht-Entwickler, Investoren und ihr Umfeld alle Code in ein System einbringen, wird Stabilität zugunsten einer übermäßigen Belohnung von Geschwindigkeit aufgegeben
- AI kann Verständlichkeit, Änderbarkeit, Debuggbarkeit, Vermittelbarkeit und Gewährleistbarkeit verschlechtern
- AI kann Systeme instabil machen, übernimmt dafür aber keine Verantwortung
- Genau das ist die zentrale Sorge von Senior-Entwicklern
Senior-Entwickler eher als Editoren denn als Autoren
- Ein möglicher Ansatz für Senior-Entwickler ist Entkopplung (decoupling)
- Lange Zeit konnten nur Softwareentwickler Software bauen, daher trugen Entwickler Verantwortung für beide Zyklen: Marktlernen und Service-Stabilität
- Ein einziges System musste beide Ziele gleichzeitig tragen
- Wenn man für die beiden Ziele unterschiedliche Systeme verwendet, lassen sich Geschwindigkeit und Stabilität voneinander trennen
- Das ähnelt dem Vorgehen eines Romanautors, der erst schnell einen Rohentwurf fertigstellt und später in einem redaktionellen Prozess die funktionierenden Teile übernimmt und die nicht funktionierenden verwirft
- Die Aufgabe des Editors besteht darin, gut funktionierende Fragmente zu nehmen und zu einem kohärenten Ganzen zu formen
- Die Speed-Version ist ein System für Geschwindigkeit, ein Raum, in dem AI-Agenten, generierter ungeprüfter Code, Junior-Entwickler und Marketing Ideen schnell umsetzen können
- Die Speed-Version zielt nicht auf Verständlichkeit, sondern darauf, gut genug zu sein, um Marktfeedback zu erhalten
- Die Scale-Version ist ein System für Stabilität, das Senior-Entwickler stabil, verständlich und skalierbar entwerfen
- Die Speed-Version ermöglicht es dem Business, weiter vom Markt zu lernen, und Senior-Entwickler bauen anschließend ein gut geprüftes und verständliches System dahinter auf
- Das Design der Scale-Version wird davon beeinflusst, was in der Speed-Version gut funktioniert hat und was nicht
- Funktionen entstehen in Speed und werden später in Scale stabilisiert
- Die konkrete Implementierungsform ist möglicherweise nicht klar, aber entscheidend ist, die Arbeit an Geschwindigkeit und die Arbeit an Stabilität explizit zu trennen
- Bei einer ambitionierten Anfrage kann man sagen: „Die Speed-Version ist in 3 Tagen bereit, die Scale-Version etwa 6 Wochen später“
- Das Gegenüber bekommt Tempo und Vorwärtsbewegung, und Senior-Entwickler gewinnen Zeit für Beobachtung und Design
- Aus dieser Perspektive könnten Senior-Entwickler eher Senior Software-Editoren sein als „Senior Software-Autoren“
1 Kommentare
Hacker-News-Kommentare
Der wichtigste Teil von Expertise entsteht aus dem internen Weltmodell und ist davon nicht zu trennen
Normalerweise glaubt man, alles lasse sich in Worte fassen, und wenn nur die Worte übertragen werden, verstehe die hörende Person genau dasselbe wie die sprechende. Aus diesem Glauben entsteht die Forderung, die Expertise von Entwicklerinnen und Entwicklern an andere „weiterzugeben“.
Tatsächlich lässt sich Wissen in Worten ziemlich gut vermitteln, aber ein verfestigtes Weltmodell, in dem alles miteinander verbunden ist, nicht. KI kann zwar sehr viel mehr Fakten kennen, nutzt dieses Wissen aber noch nicht auf eine Weise, die auf seiner Grundlage erstaunlich oft richtige Einsichten hervorbringt.
Die Vermittlung von Expertise ist in Wirklichkeit eher ein Hinweis darauf, wohin man gehen und was man lernen sollte, und die empfangende Person muss sich dieselbe Expertise durch Verinnerlichung, eigene Anstrengung und passende Projekte selbst aneignen
Man erkennt den Unterschied zwischen jemandem, der die „physikalischen Gesetze“ von Software versteht und anwendet, und jemandem, der nur Verfahren aufschreibt, ohne das Wesen der einzelnen Schritte verstehen zu wollen
Besonders deutlich wird das, wenn man Menschen mit OOP-Hintergrund funktionale Programmierung beibringt: Bei manchen bricht das Modell zusammen, andere sehen schnell, dass sich aus der Welt der Variablen relativ leicht in die Welt der Monaden übersetzen lässt
Ich habe fast 30 Jahre lang größtenteils in einem großen Konzern gearbeitet und verbringe jede Woche viel Zeit damit, Fragen von neuen Leuten zu beantworten. Oft merke ich schon an der Frage selbst, dass die Wurzel des Problems in ihrem Weltmodell liegt, in Naurs Theory, die unvollständig oder verzerrt ist und dadurch Schlussfolgerungen erschwert
Die Aufgabe besteht darin, die eigene Theorie in symbolische Darstellungen wie Text und Diagramme zu übersetzen, sodass jemand mit genügend Erfahrung und Intelligenz ein ähnliches mentales Modell aufbauen kann. Mit anderen Worten: Ich möchte meine Theorie im Kopf anderer installieren
Eine Theorie in Naurs Sinn lässt sich nicht direkt transplantieren, aber ich denke, die Arbeit von Senior-Entwicklern besteht darin, ob im Klassenzimmer oder in der Praxis, Wege zu finden, mit Hilfe von Erfahrung solche Theorien neu zu erzeugen. Deshalb sind Kommunikationsfähigkeiten wichtig, und man braucht wiederholte Erfahrungen damit, von anderen eine funktionierende Theorie zu erhalten, damit sich wirksame Instinkte bilden
Inzwischen ist das der lohnendste Teil meiner Arbeit geworden, und solange ich das Gefühl habe, diese Funktion sinnvoll zu erfüllen, möchte ich den Ruhestand nicht überstürzen
Wenn ich Juniors trainiere und mentore, versuche ich zu zeigen, was möglich ist und welche Muster in Fehlschläge führen, aber dieses Training ist meist fragmentarisch und unvollständig
Ich erkläre nach Möglichkeit, warum man etwas so macht, aber ich sage nur selten kategorisch, dass man etwas nicht tun darf. Ich bin oft überrascht, wie die Leute, die ich ausgebildet habe, Probleme lösen, und lerne selbst häufig dazu
Weniger erfolgreich ist das Training bei Menschen, die kein Interesse an ihrem eigenen Beitrag haben und Arbeit nur als Mittel zum Gehalt sehen. Das heißt nicht, dass diese Sicht falsch ist, aber wenn man sich aus Gleichgültigkeit ein Weltbild der Arbeit aufbaut, ist es schwer, Training zu verinnerlichen
https://andymatuschak.org/books/
Als Senior-Entwickler hasse ich pauschale Verallgemeinerungen wirklich
Ich habe genauso viele Fälle scheitern sehen wegen einer Haltung wie „Brauchen wir das wirklich?“, „Was passiert, wenn wir es nicht tun?“ oder „Können wir erst einmal durchhalten und später zurückkommen, wenn es wichtiger wird?“ wie Fälle, die wegen Experimentierfreude gescheitert sind
Jedes System ist anders, jedes Produkt ist anders. Wenn man Firmware für einen CT-Scanner baut, sollte man mit neuen Ansätzen anders umgehen als bei einem CRUD-SaaS mit 100 Kunden
Es gibt eindeutig Senior-Leute, die mit zu viel Leidenschaft und Offenheit ein System in Ecken treiben, aus denen man schwer wieder herauskommt, aber es gibt auch Leute, die sagen, PHP5 reiche völlig aus
Ein guter Senior muss erkennen können, wann welcher Zeitpunkt ist
Also endet es damit, dass man bei technischen Entscheidungen einfach auf den VP hört und Elasticsearch nimmt
Natürlich gibt es Situationen, in denen Handeln nötig ist, aber heute ist das Gleichgewicht zu stark in Richtung unnötiger Verkomplizierung von allem verschoben
Es geht nicht darum, keine neuen Produkte und Services zu bauen, sondern beim Bauen den Pfad mit der geringsten Gesamtentropie zu suchen. Das gilt auch für Betrieb und den Abbau technischer Schulden
Vorzeitige Optimierung ist die Wurzel allen Übels
Ob es sich um ein Startup handelt oder um einen Großkonzern mit bereits starkem Cashflow, verändert die Beurteilung, wenn man Kernfunktionen eines Produkts anfasst
Ich habe den Beitrag gern gelesen und stimme der Kernaussage zu, nämlich besser auf das Gegenüber abgestimmt zu kommunizieren
Allerdings fühlt sich das Framing so an, als starte es auf dem richtigen Weg und biege dann leicht in eine andere Richtung ab
Beide vorgestellten Schleifen profitieren davon, wenn sie enger und schneller werden. Die eine bringt ein System schneller zu einem „stabilen“ und wartbaren Arbeitspunkt, die andere dient dem Umgang mit Unsicherheit
Auch die zusätzliche Einsicht, Systeme zu trennen, um sich besser an KI anzupassen, erkläre ich schon lange mit Spikes, lange bevor KI Mainstream wurde
Ich habe festgestellt, dass es bei Junior-Entwicklern meist keine Nachfrage danach gibt, dass ich meine Expertise kommuniziere und teile
Im Großen und Ganzen sind Entwickler nicht daran interessiert, einen Mentor zu suchen. Sie schauen nicht einmal auf LinkedIn-Profile und sehen mich nicht als mögliche Quelle von Wissen und Expertise
Es ist nicht so, dass ich nach 30 Jahren in der Branche nichts zu teilen hätte, sondern dass niemand da ist, der es annehmen will
Ein weniger erfahrener Entwickler schlug vor, einen URL-Validator durch KI-Magie zu ersetzen, und ich widersprach mit einem KI-vorabgefüllten, cachebasierten Fuzzy-Matching-Ansatz, aber niemanden kümmerte es. Jetzt ist das KI-Modell plötzlich ausgefallen, und das System ist kaputt. Das ganze System muss erneut validiert werden
Ein jüngerer Entwickler, der vor mir befördert wurde, schrieb gerade ein Dokument darüber, wie man das reparieren könnte, und fragte: „Dan, kannst du mir dabei helfen?“ Er wurde befördert, weil der Weg nach vorn darin bestand, Dokumente zu schreiben und Meetings zu machen statt vernünftig zu arbeiten, und jetzt will er mit meiner Arbeit Führungsstärke beweisen
Je bessere Lösungen ich vorschlage, desto bedrohlicher wirke ich auf weniger erfahrene Entwickler, und weil es meistens irgendwie funktioniert, kümmert es Manager auch nicht. Vielleicht hätte ich besser damit umgehen können, aber ich bin zu erschöpft davon, gegen Unsinn zu kämpfen, und will einfach guten Code schreiben
Die Juniors hingegen wollten reden, zusammen Mittag essen und teilen, woran sie arbeiten. Die Seniors waren abgrenzend und für sich
Vielleicht ist das nur an unserem Arbeitsplatz so, aber das Büro ist wichtig
Einige Senior-Entwickler dort wurden wütend, wenn Juniors Fragen stellten. Schon jemanden mit 20 Jahren Erfahrung etwas zu fragen, kostete Überwindung, und mit 50% Wahrscheinlichkeit bekam man eine unfreundliche Reaktion
Es war eine gute Lernerfahrung, und heute bemühe ich mich bewusst um Mentoring
Ich habe in den letzten Jahrzehnten immer wieder Mentoring gemacht und hatte das Glück, großartige Mentees zu treffen. Einige habe ich fast zehn Jahre lang begleitet, und sie machen sich heute sehr gut
Ich habe keinen besonders hilfreichen Rat dazu, wie man sie findet, aber es gibt sie
Aber kurz nach meiner Ankunft kündigte er an, dass er gehen werde, weil er einen Nachfolger gefunden habe, und am Ende lief es für mich nicht gut
Die meisten Proofs of Concept, die ich gesehen habe, wurden bei ausreichender Traktion zu Produktion
Mehrfach wurde versprochen: „Wenn das abhebt, schreiben wir es von Grund auf neu“, aber das ist nie passiert
Der Beitrag berührt Verantwortung und Rechenschaft, aber für die Person, die das Risiko eingeht, existiert so etwas nicht. Sie schiebt eine verrückte Idee hastig raus, hofft, dass Kunden anbeißen, und profitiert davon. Wie das Ganze dann betrieben und skaliert werden soll, ohne dass die Betriebskosten den Verkaufspreis übersteigen, ist nicht ihr Problem
Es gibt Firmen, die die rechte Schleife ins Extrem getrieben haben, und zwei davon sind heute sehr bekannt. Sie bringen etwas schnell auf den Markt, skalieren nur linear und gehen dann Geld einsammeln. Es sind erfolgreiche Firmen mit unzähligen Nutzern, und einige zahlen sogar. Senior-Entwickler oder andere vernünftige Leute, die fragen „Ist das nachhaltig, und was ist unser Ausweg?“, werden entlassen, und übrig bleiben nur die Gläubigen
Wenn Ingenieure still genau das tun, was nichttechnische Stakeholder verlangen, entsteht ein Verantwortungs-Vakuum, und irgendwann explodiert es katastrophal, woraufhin die Person mit den schlechtesten Möglichkeiten zur Selbstverteidigung beschuldigt wird
Wenn man umgekehrt den Blick weit genug hebt und oft genug nach dem „Warum“ fragt, kann fast jedes Geschäftsproblem auf vernünftige Weise gelöst werden, ohne das System in schreckliche Einbahnstraßen zu drängen
Nicht überall gibt man Engineering diese Befugnis, aber dort, wo man sie nicht gibt, kann man Seniors nicht halten, die erwarten, dass ihr Urteilsvermögen respektiert wird. Manchmal sind technische Schulden geschäftlich die richtige Entscheidung, aber ein hinreichend erfahrener Ingenieur kann immer einen Ausweg offenhalten
Das bedeutet allerdings nicht, dass man die Reinheit des Systems über das Geschäftsproblem stellen darf. Die Kosten des Systems bezahlt das Geschäft, und wenn man das vergisst, verliert man auch die Grundlage seines Einflusses
Die Schlussfolgerung des Beitrags ist im Grunde der alte Rat: „Plane, eins davon wegzuwerfen.“ Ich habe auch The Mythical Man-Month gelesen, aber die Frage ist, wie man Entscheidungsträger davon überzeugt
Wenn es die Erwartungen nicht erfüllte, wurde das Feature deaktiviert oder entfernt; andernfalls wurde es nach Review ordentlich refaktoriert
Das Team hatte viel Autonomie, und es gab kaum Beschwerden über Zeitpläne, weil die meisten anderen Abteilungen ohnehin hinterherhinkten. Nur das Marketing hatte immer „Ideen“
Dass es sich um einen Prototypen oder Proof of Concept handelt, ist im Grunde irrelevant, wenn man die tatsächlichen Probleme nicht benennen kann
Viele Teams klagen darüber, in technischen Schulden zu stecken, dass dies ein großes Risiko sei und sie verlangsame, aber in den Incident-Logs gibt es kaum Vorfälle, und nichts deutet darauf hin, dass riskanter Code in Produktion schuld wäre. Auch im Risk Register steht nichts wie „Dieser Code ist alt, schrecklich und hängt von nicht mehr unterstützten Abhängigkeiten ab“, und kein Team kann erklären, wie und in welchem Ausmaß technische Schulden es verlangsamen
Auf der anderen Seite habe ich Teams gesehen, die vor dem Release monatelang refaktoriert haben, weil sie ihre App noch „besser“ machen wollten. Jegliche Wertlieferung wurde verzögert, die Führung war natürlich wütend, und fast kein Vertrauen blieb übrig
Zwischen Team und Stakeholdern muss es gute Gespräche über Lieferung geben, damit alle zufrieden sein können, aber wenn es sie nicht gibt, gewinnen die Stakeholder immer
Hier wird das grundlegende Problem der Anreize übersehen. Es ist nicht wichtig, was „die Firma“ will, sondern was die Menschen wollen, die konkrete Entscheidungen treffen
Es gibt Leute, deren Stelle davon abhängt, neue Features oder Apps zu launchen, damit irgendwo in den Unternehmensmetriken etwas auftaucht. Wenn ein Senior-Entwickler sagt, es sei eine schlechte Idee, hören diese Leute entweder nicht zu oder es ist ihnen egal. Ihr eigener Job steht auf dem Spiel
Aber wenn es um Produkte geht, müssen Features an Kundenanforderungen ausgerichtet sein, also muss man Forschende davon abhalten, Dinge einfach durchzudrücken
Wirklich fähige Seniors erkennen, was in ihrem aktuellen Unternehmen die vorherrschende Kultur ist und was in fünf Jahren gebraucht wird, und passen sich daran an
Ein Startup mit fünf Leuten braucht vielleicht keine zusätzliche Komplexität, die die Runway verkürzt. Ein Unternehmen mit 500 Leuten braucht diese Komplexität vielleicht, um die Effekte zweiter Ordnung geschäftlicher Entscheidungen abzufedern
Es ist keine Schwarz-Weiß-Logik von „Komplexität immer vermeiden“, sondern „Komplexität hinzufügen, wenn es sinnvoll ist“, und schon diese Frage wird sehr subtil, wenn das Unternehmen vielleicht nur noch ein paar Monate überleben muss
Wenn in zwei Stunden der Sturm kommt, denkt man weniger über Architektur nach und fragt eher: „Wird so viel Wasser hereinkommen, dass wir es nicht mehr herausschöpfen können?“
Das Problem, das ich sehe, ist, dass das Management Spielchen spielt und nicht sagt, wie viel Geld tatsächlich noch da ist oder wie der echte Zeitplan aussieht. Sie haben Angst, dass die Beitragenden vor den entscheidenden Momenten abspringen. Dadurch treffen Menschen in diesem Kontext weiter dumme Entscheidungen, und am Ende suchen alle einen neuen Job
Seit ein paar Tagen versuche ich, meinem Team fast genau dieselbe Stimmung zu vermitteln, bis hin zu dem Satz: „Müssen wir wirklich eine ganze neue Funktion bauen und testen? Haben wir einfach mal einen Button in die bestehende UI gesetzt und geschaut, ob Leute draufklicken?“
Es fühlt sich an, als ob die Produktseite kollektiv beschlossen hätte, ihre eigenen geistigen Fähigkeiten nicht mehr einsetzen zu müssen, und die Engineers leiden jetzt darunter. Erst bauen, und Nutzer-Personas sowie Nützlichkeit später oder nie herausfinden
Früher hat man Zeit darauf verwendet zu verstehen, wie Domain, Nutzer und Produkt in einen Prozess passen; jetzt veröffentlicht man einfach, was imaginäre Nutzer angeblich wollen, und experimentiert, bis es erfolgreich ist
Genau das Problem aus dem ursprünglichen Beitrag tritt auf. Jedes per Vibe Coding erzeugte Zufallsfeature wird zu einer Quelle von Instabilität und Risiko, und weil niemand ein funktionierendes mentales Modell des Gegenstands hat, lässt es sich nur noch mit noch mehr Vibe Coding warten
Selbst wenn man Komplexität auf eine einzige Messdimension reduzieren könnte, wäre sie nur ein Faktor unter vielen im Lösungsraum
Es gibt andere Eigenschaften wie Wartbarkeit, Skalierbarkeit, Zuverlässigkeit, Resilienz, Antifragilität, Erweiterbarkeit, Generalität, Langlebigkeit und Komponierbarkeit, und nicht alle davon sind immer relevant
Die Fähigkeit, nicht in einer einzelnen Dimension, sondern in Trade-offs im Lösungsraum zu sprechen, ist aus meiner Sicht das, was Senior- und Staff+-Entwickler voneinander unterscheidet
Wenn man sie hingegen als etwas versteht, das die Entwicklung dieses Systems über die nächsten zehn Personenjahre leichter und schneller macht, dann bedeutet sie die Wahl, seitlich auszuweichen, wo ein naiver Ansatz frontal durchbrechen würde
Wie in der Geschichte von Hase und Schildkröte ist es schwer zu begreifen, dass ein Verlauf, in dem man die ersten zwei Wochen mit Eile, Low-Hanging Fruit, sichtbaren Erfolgen und einem MVP verbrät und danach durch unreifes Design und Wartung während der Entwicklung immer langsamer wird, zwar ein paar Wochen lang „schnell“ aussieht, am Ende aber den Termin um sechs Monate verschiebt
Als Programmierer muss man irgendwann erkennen, dass letztlich jeder mögliche Aspekt eines Designs ein Trade-off ist