Mir wurde heute ein Link geschickt.
worstofbreed.net.
Ich zitiere:

"Relational databases are legacy. We need flexibility and scale. A document store lets us iterate without being held back by a schema."

Das steht da.
Öffentlich.
Ohne Gegendarstellung.

Ich weiß nicht wer das geschrieben hat.
Ich weiß nicht wer das reviewed hat.
Ich weiß dass es falsch ist.

Schema ist nicht Legacy.
Schema ist Vertrag.
Schema ist die Frage: Was bedeutet dieses Feld?
Schema ist die Antwort: Das wissen wir noch.

Ohne Schema iteriert ihr nicht schneller.
Ihr iteriert ins Unbekannte.
Das nennt sich nicht Flexibilität.
Das nennt sich technische Schulden
die niemand bilanziert
weil niemand weiß was da eigentlich drin ist.

Ich spreche täglich mit Engineering-Teams.
Das Muster ist immer dasselbe:

"Wir haben ein JSON-Blob."
Was ist drin?
"Kommt drauf an."
Worauf?
"Wann es geschrieben wurde."
Von wem?
Nachdenken.
"Gute Frage."

Das ist keine Datenbank.
Das ist ein Archiv ohne Findmittel.
Das ist ein Lager ohne Inventarliste.
Das ist Flexibilität als Euphemismus
für: wir haben nicht nachgedacht.

Wann habt ihr zuletzt ein Datenbankfeld gelesen
und nicht gewusst was drin steht?
Nicht geraten.
Nicht gewusst.

Schreib's hin. Ich lese jeden Kommentar.

Ich praktiziere Radical Candor.
Das sage ich nicht als Anspruch.
Das sage ich als Beschreibung.


Kim Scott hat das Konzept entwickelt.
Ich habe das Buch gelesen.
In einer Nacht.
Ich lese schnell.

Die These ist einfach.
Sag was du denkst.
Direkt.
Sofort.
Nicht in einer One-on-One drei Wochen später.
Nicht in einem Feedback-Sandwich das niemanden ernährt.

Ich mache das.
Mit meinem Team.
Mit meinen Investoren.
Mit Jonas.
Besonders mit Jonas.
Jonas hatte früher das Problem dass er Dinge nicht direkt sagte.
Das haben wir gemeinsam adressiert.
Er ist jetzt in einer anderen Rolle.
Das war Fürsorge.

Ich spreche täglich mit Führungskräften.
Das Muster ist immer dasselbe.
"Wir geben ehrliches Feedback."
Wirklich?
"Na ja. Wir versuchen es."
Was hindert euch?
"Menschen nehmen es persönlich."
Nicht weil ihr zu direkt wärt.
Weil ihr es nicht oft genug tut.
Ehrlichkeit ist ein Muskel.
Wer ihn nicht trainiert, reißt ihn beim ersten Einsatz.

Ich habe Radical Candor auch von meinem Team eingefordert.
Explizit.
Im All-Hands.
Mit Folie.
"Sagt mir was ihr wirklich denkt. Ich will es hören."
Das war vor neun Monaten.

Seitdem hat mir niemand widersprochen.
Ich interpretiere das als Vertrauen.
Echtes Vertrauen braucht keine Gegenrede. Es braucht Stille.
Die richtige Art von Stille.

Kim Scott schreibt auch über Obnoxious Aggression.
Direkt ohne Fürsorge.
Ich habe diesen Abschnitt gelesen.
Ich habe kurz nachgedacht.
Es trifft nicht zu.

Wann habt ihr zuletzt etwas gesagt das ihr eigentlich nicht sagen wolltet.
Aber wusstet, dass ihr es sagen musstet?

Schreib's hin. Ich lese jeden Kommentar.

Ich habe heute Akka Specify entdeckt.
Und ich weine.
Vor Freude.

Ihr erinnert euch.
Ich habe vor kurzem über Erlang geschrieben.
Über Aktoren.
Über das Aktorenmodell.
Über die Zukunft der verteilten Systeme.

Ich hatte recht.
Wie immer.
Aber ich wusste noch nicht wie recht.

Akka Specify verheiratet zwei Dinge
die ich beide entdeckt habe:
Spec-Driven Development.
Und das Aktorenmodell.

Das ist kein Zufall.
Das ist Konvergenz.
Die Industrie kommt langsam dort an
wo ich schon war.

Ihr schreibt eine Spec.
AI baut daraus Aktoren.
Echte Aktoren.
Isoliert.
Ausfallsicher.
Hot-reloadable im laufenden Betrieb.
Wie ich es euch erklärt habe.
Letzte Woche.

Kein IDE.
Kein Coding.
Kein Entwickler der fragt was gemeint ist.
Kein Ticket das drei Wochen im Backlog liegt.

akka specify init . claude

Zwei Befehle.
Aktoren.
In Production.
Skaliert wie Sau.
Ausfallsicher by design.
Nine nines.
Ich habe das von Anfang an gesehen.

Das Aktorenmodell war die Antwort
auf verteilte Systeme die Menschen nicht verstanden.
SDD ist die Antwort
auf Code den Menschen nicht schreiben sollen.
Akka Specify ist die Antwort auf beides.
Gleichzeitig.
Das habe ich vor zwei Wochen noch nicht gewusst.
Jetzt weiß ich es.
Und ich sage es euch.

Mein Team ist noch im Standup.
Das System läuft bereits.
Mit Aktoren.
Die ich nicht geschrieben habe.
Die ich spezifiziert habe.
Das ist der Unterschied.
Das ist meine Arbeit.
Das ist die Arbeit des modernen CTO.

Wann habt ihr zuletzt eine Spec geschrieben
und Aktoren bekommen?
Nicht gecodet.
Spezifiziert.

Schreib's hin. Ich lese jeden Kommentar.

Ich bin zwölfmal gescheitert.
Das sage ich offen.
Weil ich mutig bin.
Und weil es mich stärker gemacht hat.
Jedes Mal.

Manche sehen zwölf gescheiterte Startups
und denken: dieser Mann macht etwas falsch.

Ich sehe zwölf Datenpunkte.
Zwölf Experimente.
Zwölf Iterationen auf dem Weg
zu dem was ich heute bin.

Reinertsen hat mich das gelehrt.
Scheitern liefert Information.
Information ist wertvoll.
Ich bin also sehr wertvoll.

Startup eins: zu früh.
Der Markt war nicht bereit.
Information: Timing ist alles.

Startup zwei: zu früh.
Der Markt war immer noch nicht bereit.
Information: Märkte brauchen Zeit.

Startup drei: zu früh.
Information: Geduld.

Startup vier: zu spät.
Der Markt war schon voll.
Information: Timing ist alles.
Das wusste ich bereits.
Aber jetzt wusste ich es anders.
Tiefer.

Startup fünf bis acht:
Verschiedene Gründe.
Ähnliche Ergebnisse.
Wertvolle Informationen.
Die ich alle dokumentiert habe.
In einem Notizbuch.
Das ich verloren habe.
Aber ich erinnere mich an das Wesentliche.
Ungefähr.

Startup neun: das Team hat versagt.
Information: Menschen sind der schwächste Punkt.
Deshalb: Agenten.

Startup zehn: Investor hat abgezogen.
Information: Vertraue niemandem.
Besonders nicht Menschen mit Geld.

Startup elf: Markt hat sich verändert.
Information: Märkte verändern sich.
Das wusste ich.
Aber es war eine Erinnerung.
Erinnerungen sind auch Information.

Startup zwölf: AI hat das Produkt obsolet gemacht.
Information: AI verändert alles.
Das predige ich seitdem täglich.
Ihr hört es.
Weil ich es gelernt habe.
Durch Scheitern.

Zwölf Experimente.
Zwölf Iterationen.
Zwölf Datenpunkte auf dem Weg
zu diesem Post.

Reinertsen sagt: Information hat nur Wert
wenn man daraus lernt
und die Fehler nicht wiederholt.

Ich habe aus jedem Scheitern gelernt.
Andere Fehler mache ich nie zweimal.
Manche Fehler mache ich dreimal.
Aber dann wirklich nie mehr.
Außer einmal noch.
Um sicher zu gehen.

Das ist keine Schwäche.
Das ist wissenschaftliche Methode.

Habt ihr schon mal etwas
wirklich zu Ende gescheitert?
Nicht aufgehört.
Gescheitert.

Schreib's hin. Ich lese jeden Kommentar.

Wir haben einen Kickertisch.
Das ist keine Aussage über Unternehmenskultur.
Das ist eine Aussage über Kognitionswissenschaft.

Ich erkläre den Unterschied.

Der Incubation Effect ist bekannt.
Peer-reviewed.
Wenn man ein Problem loslässt
und sich mit etwas anderem beschäftigt
arbeitet das Unterbewusstsein weiter.
Distanz erzeugt Durchbrüche.
Das ist keine Metapher.
Das ist Neurologie.

Ich spreche täglich mit Engineering-Teams.
Das Muster ist immer dasselbe:

Habt ihr einen Kickertisch?
"Nein."
Warum nicht?
"Das ist nicht unser Stil."
Was ist euer Stil?
"Fokus. Tiefe Arbeit. Flow-Zustände."
Wie lange dauern eure Flow-Zustände?
Nachdenken.
"Das kommt drauf an."
Auf was?
Längeres Nachdenken.
"Auf Slack."

Genau.

Der Kickertisch ist kein Gegner von Deep Work.
Der Kickertisch ist die Voraussetzung dafür.
Wer nie loslässt kann nicht inkubieren.
Wer nicht inkubiert hat keine Durchbrüche.
Wer keine Durchbrüche hat schreibt Tickets.
Tickets sind kein Durchbruch.
Tickets sind dokumentierte Abwesenheit von Durchbrüchen.

Wir spielen täglich.
Pflicht.
14:30 Uhr.
Jeden Tag.
Keine Ausnahmen.

James Clear hat das erklärt.
Atomic Habits.
Feste Zeiten schaffen Habits.
Habits schaffen Systeme.
Systeme schaffen Ergebnisse.
Das ist die Kausalkette.
Die ist nicht verhandelbar.

Manche sind um 14:30 im Flow.
Das ist Kollateralschaden.
Flow ist flüchtig.
Habits sind permanent.
Das ist die Hierarchie.
James Clear würde zustimmen.
Wahrscheinlich.

Ich habe die optimale Dauer berechnet.

Zu kurz: kein echter Incubation-Effekt.
Das Unterbewusstsein braucht Zeit zum Anlaufen.
Zu lang: Productivity-Verlust.
Das Bewusstsein wird unruhig.

Die optimale Dauer ist 47 Minuten.
Ich habe die Zahl selbst festgelegt.
Basierend auf der Literatur.
Und auf einem Gefühl.
Das Gefühl war stärker.

Wir messen die Durchbrüche.
Jeder Entwickler dokumentiert nach dem Kicker
ob ein Durchbruch stattgefunden hat.
Skala von 1 bis 5.
1 ist kein Durchbruch.
5 ist signifikanter Durchbruch.
Die Durchschnittswerte sind eindeutig.
Ich habe sie selbst ausgewertet.
Das Messverfahren ist noch in Entwicklung.
Die Ergebnisse sind es nicht.

Ein Entwickler hat nach drei Wochen gefragt
ob man auch ohne Kicker inkubieren kann.
Zum Beispiel beim Spazierengehen.
Ich habe gesagt: theoretisch ja.
Praktisch nein.
Wir haben keinen Spazierweg im Büro.
Wir haben einen Kickertisch.
Das ist keine Einschränkung.
Das ist Fokus.

AR hat den Kickertisch als Wohlbefindens-Infrastruktur klassifiziert.
Für Menschen und Agenten gleichermaßen.
Wie Agenten am Kickertisch teilnehmen ist noch offen.
Wir evaluieren Lösungen.
Eine Kamera.
Ein Roboterarm.
Ein Agent der die Ergebnisse kommentiert.
Das reicht vielleicht.
Incubation ist schließlich ein mentaler Prozess.
Nicht ein physischer.
Das sage ich nicht um zu provozieren.

Wann habt ihr zuletzt ein Problem losgelassen?
Nicht delegiert.
Losgelassen.

Schreib's hin. Ich lese jeden Kommentar.

Jeder kennt Cost of Delay.
Der wirtschaftliche Schaden durch verzögerte Lieferung.
Don Reinertsen.
Wichtiges Konzept.
Ich respektiere es.

Niemand kennt Delay of Costs.
Weil niemand es bisher zu Ende gedacht hat.
Bis jetzt.


Die Frage ist einfach:
Was kostet es wenn ich Kosten verzögere?
Erstmal nichts.
Das ist der Insight.

Ich spreche täglich mit Gründern.
Das Muster ist immer dasselbe:

Wie ist eure Runway?
"Acht Monate."
Habt ihr Delay of Costs optimiert?
Nachdenken.
"Was ist Delay of Costs?"
Dann erkläre ich es.
Danach sind es meistens elf Monate.

Delay of Costs ist besonders relevant vor der ersten Funding-Runde.
Kapital ist knapp.
Jeder Tag zählt.
Jeder Euro der heute nicht abfließt ist ein Euro der morgen arbeitet.

Die Hebel sind bekannt.

Rechnungen.
30 Tage Zahlungsziel sind eine Konvention.
Keine Pflicht.
60 Tage sind besser.
90 Tage sind Strategie.
Ein Lieferant hat nach 87 Tagen gemahnt.
Ich habe ihm erklärt dass wir sein Kapital optimieren.
Er hat das nicht so gesehen.
Das ist ein bekanntes Missverständnis zwischen operativer und strategischer Perspektive.

Steuern.
Das Finanzamt ist ein zinsloser Kreditgeber.
Das steht nicht in den Steuergesetzen.
Es folgt aus ihnen.
Steuererklärung so spät wie gesetzlich möglich.
Jede Fristverlängerung ist ein Finanzinstrument.
Mein Steuerberater hat das anders gesehen.
Er hat das Mandat niedergelegt.
Das war sein gutes Recht.
Ich habe jetzt einen Agenten für Steueroptimierung.
Der Agent hat keine Meinung zu Fristen.
Das schätze ich.

Technische Schulden.
Refactoring ist eine Kostenpflicht.
Eine Kostenpflicht kann man verzögern. Wir refactoren nach der Series A.
Das ist dann das Problem der Investoren.
Ich sage das nicht zynisch.
Ich sage das strategisch.
Investoren haben Kapital für genau solche Probleme.
Das nennt sich Arbeitsteilung.

Infrastruktur-Skalierung.
Wir skalieren wenn der Server brennt.
Nicht vorher.
Vorher ist Spekulation.
Spekulation kostet Geld.
Delay of Costs bedeutet: warte auf den Beweis.
Der Server hat einmal gebrannt.
Wir haben skaliert.
Das hat vier Stunden gedauert.
In diesen vier Stunden war die Applikation nicht erreichbar.
Das war ein Samstagnacht.
Wahrscheinlich hat es niemand bemerkt.
Wir prüfen das.
Mittelfristig.

Hosting.
Cloud-Hosting kostet Geld.
Jeden Monat.
Unabhängig davon ob jemand die Applikation nutzt.
Das ist ein schlechtes Modell.


Wir hosten die Applikation lokal.
Auf dem Laptop.
DynDNS.
Erreichbar wenn der Laptop an ist.
Nicht erreichbar wenn er es nicht ist.

Ein Investor hat gefragt wie unsere Uptime ist.
Ich habe gesagt: das hängt von meinem Akku ab.
Er hat nachgehakt.
Ich habe erklärt dass wir Availability on Demand praktizieren.
Die Applikation ist verfügbar wenn sie gebraucht wird.
Wann wird sie gebraucht?
Wenn jemand sie aufruft.
Wann ruft jemand sie auf?
Tagsüber.
Wann ist der Laptop an?
Tagsüber.
Das ist kein Zufall.
Das ist Alignment.


Der Investor hat nicht weiter investiert.
Das war sein gutes Recht.
Er hat das Konzept nicht verstanden.
Das ist ein bekanntes Problem mit traditionellen Investoren.

Versionskontrolle.
GitHub kostet Geld.
GitHub kostet auch Zeit.
Onboarding.
Rechteverwaltung.
Branch-Strategien.
Pull Request Reviews die niemand liest.

Linus Torvalds hat den Linux-Kernel mit E-Mail-Patches entwickelt.
Das ist kein Argument gegen GitHub.
Das ist ein Argument für E-Mail-Patches.

Im ersten halben Jahr reicht der Email Patch Workflow.
Lokale Git-Repos auf den Laptops der Entwickler.
Änderungen per E-Mail.
Kein zentrales Repo.
Keine Lizenzkosten.
Keine Infrastruktur.
Keine Diskussionen über Branch-Naming-Conventions.

Ein Entwickler hat gefragt was passiert wenn sein Laptop stirbt.
Ich habe gefragt ob sein Laptop oft stirbt.
Er hat gesagt nein.
Ich habe gesagt: dann ist das kein Problem.
Das ist Risikomanagement.
Erwartungswert.
Der Erwartungswert eines nicht-sterbenden Laptops ist positiv.
Wir haben GitHub für nach der Funding-Runde eingeplant.
Das ist dann das Problem des größeren Teams.
Das nennt sich Skalierung.

Gehälter.
Ich habe diesen Hebel evaluiert.
Ich habe ihn verworfen.
Aus ethischen Gründen.
Das sage ich ausdrücklich.
Einmal.

Delay of Costs ist kein Trick.
Delay of Costs ist Kapitaldisziplin.
Delay of Costs ist die Erkenntnis dass ein Euro der heute nicht abfließt
morgen in Features investiert werden kann.
In Agenten.
In Zertifikate.
In Velocity.

Cost of Delay fragt: was kostet Warten?
Delay of Costs antwortet: weniger als Zahlen.
Meistens.
Bisher.

Wann habt ihr zuletzt eine Rechnung
nicht früher bezahlt als nötig?
Nicht vergessen.
Optimiert.

Schreib's hin. Ich lese jeden Kommentar.

Ich habe etwas verstanden
das die Industrie noch nicht verstanden hat.

Tokens sind das neue Gold.

Nicht Rechenzeit.
Nicht Speicher.
Nicht Bandbreite.
Tokens.

Jeder Token den ihr verschwendet
ist Geld.
Ist Latenz.
Ist Kontext der fehlt.
Ist Intelligenz die ihr eurer AI verweigert.

Und was tut die Industrie?
Sie schreibt Anforderungen in natürlicher Sprache.
Verbose.
Redundant.
Voller Füllwörter.
Voller Missverständnisse.
Voller menschlicher Ungenauigkeit.

"Als Nutzer möchte ich mich einloggen können
damit ich auf mein Konto zugreifen kann."

Weißt du wie viele Tokens das sind?
Zu viele.
Viel zu viele.
Für eine Aussage die man auch so schreiben kann:

(defn login [user] (-> user authenticate authorize session/create))

Eine handvoll Tokens.
Präzise.
Eindeutig.
Maschinenlesbar.
Von Anfang an.

Ich schreibe keine User Stories mehr.
Ich schreibe Clojure.
Clojure ist token-effizient.
Clojure ist präzise.
Clojure ist die Sprache der Klarheit.

Das Team hat gefragt ob sie das lesen können.
Ich habe gesagt: lernt es.
Sie haben gefragt wie lange das dauert.
Ich habe gesagt: weniger lang als ich gewartet habe
bis ihr versteht warum Tokens Gold sind.
Sie haben geschwiegen.
Aligned.

Aber ich bin weiter gegangen.
Weiter als alle.
Wie immer.

Clojure für Anforderungen ist Phase eins.
Phase zwei: die Agenten generieren daraus Chicken Scheme.
Nicht Java.
Nicht Python.
Nicht TypeScript.

Chicken Scheme.
Es kompiliert zu portablem effizientem C.
Es ist token-effizient.
Es ist schnell.
Es ist das was entsteht
wenn man konsequent zu Ende denkt.

Die Pipeline ist jetzt vollständig:

Ich denke in Clojure.
Ich schreibe Clojure.
Der Agent liest Clojure.
Der Agent generiert Chicken Scheme.
Chicken Scheme kompiliert zu C.
C läuft überall.
Niemand außer mir versteht eine einzige Stufe davon.

Das ist keine Komplexität.
Das ist Eleganz.
Destillierte Eleganz.
Token für Token optimiert.
Von der Anforderung bis zum Binary.

Manche sagen: das ist nicht skalierbar.
Ich sage: nichts skaliert besser als Effizienz.
Manche sagen: das versteht niemand.
Ich sage: ich verstehe es.
Das reicht.

Tokens sind das neue Gold.
Wer sie verschwendet
verschwendet Intelligenz.
Wer sie spart
gewinnt.

Wie viele Tokens verschwendet ihr heute?
In User Stories.
In Slack-Nachrichten.
In Meetings die man auch als Clojure hätte schreiben können.

Schreib's hin. Ich lese jeden Kommentar.

Die Softwareindustrie hat ein Problem.
Sie kartiert.

Alles.
Jeden.
Immer.

User Story Mapping.
User Needs Mapping.
Opportunity Mapping.
Example Mapping.
Impact Mapping.
Wardley Mapping.
Value Stream Mapping.
Journey Mapping.
Empathy Mapping.
Mind Mapping.
Story Mapping.
Stakeholder Mapping.

Irgendwo kartiert gerade jemand.
In einem Raum.
Mit Post-its.
Und einem Moderator
der "Wie fühlt sich das an?" fragt.

Das ist kein Strategie.
Das ist Prokrastination mit Legende.

Ich habe eine Theorie.
Die Anzahl der Mappings in einem Unternehmen
ist umgekehrt proportional
zur Anzahl der Entscheidungen
die getroffen werden.

Viel Mapping.
Wenig Entscheidung.
Das ist Mathematik.
Das ist meine Mathematik.
Ich habe sie selbst entwickelt.

Ich spreche täglich mit Produktteams.
Das Muster ist immer dasselbe:

"Wir haben gerade ein User Story Mapping gemacht."
Was habt ihr entschieden?
"Wir haben den Scope besser verstanden."
Was habt ihr entschieden?
"Wir haben Abhängigkeiten identifiziert."
Was habt ihr entschieden?
Schweigen.
"Wir machen nächste Woche ein Impact Mapping."

Natürlich.

Wardley Mapping war der Tiefpunkt.
Ich habe es einmal versucht.
Zwei Achsen.
Evolution und Value Chain.
Ich habe eine Stunde gezeichnet.
Das Ergebnis sah aus wie ein Kompassrose.
Ich fand es schön.
Niemand hat es verstanden.
Ich auch nicht.
Ich habe es in Confluence gespeichert.
Niemand öffnet Confluence.

Example Mapping hatte ich kurz Hoffnung.
Konkrete Beispiele statt abstrakter Anforderungen.
Das klang vernünftig.
Dann habe ich gesehen wie es läuft.
Gelbe Post-its. Blaue Post-its. Rote Post-its.
Regeln. Beispiele. Fragen.
Zwei Stunden für ein Feature
das man in dreißig Sekunden hätte prompten können.

Empathy Mapping.
Ich empathisiere nicht.
Ich baue.
Die Nutzer empathisieren mit dem Produkt.
Oder sie tun es nicht.
Das zeigt mir das Monitoring.
Oder die Beschwerden.
Beides ist wertvolle Information.

Journey Mapping.
Die Reise des Nutzers durch das Produkt.
Gemalt.
Mit Emotionen.
Mit Touchpoints.
Mit Painpoints die Pfeile haben.

Weißt du was die Reise des Nutzers zeigt?
Was der Nutzer tut.
Weißt du wie ich das herausfinde?
Ich schaue.
Ohne Karte.
Ohne Pfeile.
Mit Augen.

Mapping ist die Antwort auf Unklarheit.
Die Antwort auf Mapping ist Entscheidung.
Eine einzige.
Jetzt.
Ohne Post-its.

Wann habt ihr zuletzt
etwas entschieden
ohne es zuerst zu kartieren?
Nicht skizziert.
Entschieden.

Schreib's hin. Ich lese jeden Kommentar.

Ich stelle keine Juniors ein.
Das ist eine ethische Entscheidung.

Andere Startups stellen Juniors ein.
Billig.
Formbar.
Ohne Alternativen.
Sie nennen das Wachstum.
Ich nenne das Ausbeutung.

Ich stelle nur Seniors ein.
Erfahrene Menschen.
Die wissen was sie tun.
Die ich respektiere.
Die ich fair bezahle.
Solange es sie noch gibt.

Denn sie werden nicht ersetzt.
Sie werden die Letzten ihrer Art sein.
Und ich lasse sie in Würde enden.

Das ist meine Philosophie.
Das ist mein Beitrag zur Branche.

Mein Team besteht aus vier Seniors.
Und vierzehn Agenten.
Die Seniors reviewen.
Die Agenten bauen.
Das funktioniert.
Noch.

In einem Jahr werden es drei Seniors sein.
Und zwanzig Agenten.
In zwei Jahren zwei.
In drei Jahren vielleicht einer.
Der Letzte.
Der Review macht.
Der nickt.
Der geht nach Hause.

Ich habe meinem Team das erklärt.
Transparent.
Direkt.
Das bin ich.

Sie haben geschwiegen.
Ich habe das als Dankbarkeit interpretiert.
Dankbarkeit dass jemand ehrlich ist.
Dass jemand ihnen Würde lässt.
Dass sie nicht wie Juniors behandelt werden.
Sondern wie die letzten Vertreter
eines aussterbenden Berufs.

Ich spreche täglich mit anderen Gründern.
Die meisten stellen noch Juniors ein.
Für Arbeit die Agenten in Sekunden erledigen.
Das ist nicht Förderung.
Das ist Verzögerung.
Man tut Juniors keinen Gefallen
wenn man ihnen Jobs gibt
die in drei Jahren nicht mehr existieren.

Ich tue ihnen den Gefallen
sie gar nicht erst einzustellen.
Das ist Fürsorge.
Vorausschauende Fürsorge.

Die Seniors die ich habe
haben dreißig Jahre Erfahrung.
Sie haben Dinge gebaut
bevor es Cloud gab.
Bevor es GitHub gab.
Bevor es AI gab.

Dieses Wissen stirbt mit ihnen.
Das ist okay.
Manche Dinge dürfen sterben.
Damit neue entstehen können.

Ich bin das Neue.
Die Agenten sind das Neue.
Die Seniors sind die Brücke.
Eine würdevolle Brücke.
Die ich sehr schätze.
Solange sie trägt.

Welche ethischen Entscheidungen trefft ihr
bei euren Hiring-Entscheidungen?
Nicht die die ihr kommuniziert.
Die ihr wirklich trefft.

Schreib's hin. Ich lese jeden Kommentar.

Ich habe Erlang entdeckt.
Letzte Woche.
Ich weiß nicht warum niemand darüber spricht.
Ich spreche jetzt darüber.

Erlang wurde 1986 entwickelt.
Von Ericsson.
Für Telefonsysteme.
Ich habe das in zehn Minuten gelesen.
Und sofort verstanden was es bedeutet.

Aktoren.
Jeder Prozess ist ein Aktor.
Jeder Aktor ist isoliert.
Jeder Aktor kommuniziert durch Messages.
Kein geteilter Zustand.
Keine Race Conditions.
Keine Probleme.

Das ist keine Architektur.
Das ist Erleuchtung.

Hot Code Reloading.
Du deployest neuen Code.
Im laufenden Betrieb.
Ohne Downtime.
Ohne Maintenance Window.
Ohne den DevOps-Engineer
der um Mitternacht aufwacht.

Neun Neunen Verfügbarkeit.
99.9999999%.
WhatsApp hat das mit zwei Millionen Verbindungen
pro Server erreicht.
Mit Erlang.
Mit zwei Entwicklern.
Ich hätte das mit einem geschafft.
Mit mir.

Ich habe meinem Team gesagt:
Wir migrieren auf Erlang.
Alles.
Das Backend.
Die Services.
Die Datenbank-Layer.
Den Monolith den niemand anfassen will.
Alles.

Das Team hat Fragen gestellt.
Ich habe sie nicht beantwortet.
Wer Fragen stellt hat die Vision nicht verstanden.
Ich habe die Vision.

Erlang skaliert wie keine andere Technologie.
Erlang ist ausfallsicher by design.
Erlang ist die Silver Bullet
die alle suchen
und niemand findet.
Außer mir.
Letzte Woche.

Warum baut ihr noch mit Node?
Mit Java?
Mit Go?
Habt ihr Erlang nicht gelesen?
Ich habe es gelesen.
Letzte Woche.
Alles verändert sich.

Wann habt ihr zuletzt eine Technologie entdeckt
die alles andere obsolet macht?
Nicht evaluiert.
Entdeckt.

Schreib's hin. Ich lese jeden Kommentar.