Clojure war ein Anfang.
Kein Ziel.

Ich schreibe Anforderungen in Clojure.
Das war Phase eins.
Phase eins ist abgeschlossen.
Phase eins war nicht genug.

Das Problem mit Clojure:
Clojure ist generisch.
Clojure kennt keine Domäne.
Clojure weiß nicht was ein Bestellprozess ist.
Clojure weiß nicht was ein Nutzer ist.
Clojure weiß nicht was unser Geschäft ist.

Das kostet Tokens.
Jedes Konzept das die Sprache nicht kennt
muss erklärt werden.
Jede Erklärung kostet Tokens.
Tokens sind Gold.
Das habe ich bereits erklärt.

Die Lösung ist bekannt.
Domain-Specific Languages.
DSLs.
Eine Sprache pro Domäne.
Nur die Konzepte die zählen.
Kein Rauschen.
Keine Generizität.
Keine verschwendeten Tokens.

Ich habe angefangen DSLs zu bauen.
Eine für Bestellprozesse.
Eine für Nutzerverwaltung.
Eine für Zahlungsabwicklung.
Eine für Reporting.
Eine für interne Kommunikation.
Eine für Meetings.
Eine für Entscheidungen.

Das war Phase zwei.
Phase zwei war gut.
Phase zwei war noch nicht gut genug.

Das Problem mit Phase zwei:
Bezeichner.

processOrder sind zwölf Zeichen.
Zwölf Zeichen sind zwölf Zeichen zu viel.
po sind zwei Zeichen.
p ist ein Zeichen.
Ein Zeichen ist das Minimum.
Das Minimum ist das Ziel.

Ich habe alle Bezeichner überarbeitet.
Alles was länger als drei Zeichen war
ist jetzt ein bis drei Zeichen.
Kontext ersetzt Länge.
Domänenwissen ersetzt Lesbarkeit.
Effizienz ersetzt Konvention.

Das Ergebnis:

(d u (-> r a s/c))

Ich weiß was das bedeutet.
Ihr nicht.
Das ist kein Problem.
Ihr müsst es nicht wissen.
Der Agent weiß es.
Der Agent hat es gebaut.

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

Wie viele DSLs habt ihr?
"Keine."
Warum nicht?
"Weil niemand sie lesen kann außer dem der sie geschrieben hat."
Genau.
Nachdenken.
"Das ist doch das Problem."
Das ist die Lösung.

Wir haben 34 DSLs.
Jede ist optimal für ihre Domäne.
Jede minimiert Tokens. Jede ist von einem Agenten gebaut.
In einem Nachmittag.

Manche Agenten erinnern sich nicht mehr an die DSL.
Das ist ein bekanntes Problem.
Ich erinnere mich.
Meistens.
Das reicht.

Wann habt ihr zuletzt eine Sprache gebaut
statt eine benutzt?
Nicht konfiguriert.
Gebaut.

Schreib's hin. Ich lese jeden Kommentar.

Die meisten CTOs treffen keine echten Entscheidungen mehr.

Die meisten Entwickler verstehen ihre eigene Architektur nicht.

Die meisten Product Owner haben noch nie mit einem echten Nutzer gesprochen.

Die meisten Engineering-Teams deployen zu selten.

Die meisten Unternehmen haben keine Ahnung was ihre Daten wert sind.

Die meisten.
Fast alle.
Ihr.
Nicht ich.

Ich sage das nicht weil ich es weiß.
Ich sage es weil mir jemand erklärt hat
dass leicht beleidigende Generalisierungen
Klicks bringen.
Engagement.
Reichweite.

"Die meisten X tun Y nicht."
Jeder der X ist liest das
und denkt: ich schon.
Und kommentiert.
Weil er beweisen will dass er die Ausnahme ist.

Sie triggern.
Sie regen auf.
Sie bringen Engagement.
Das ist der Algorithmus.
Das ist LinkedIn.
Das ist dieses Spiel.

Ich spiele es.
Transparent.
Jetzt.

Denn das Ehrlichste was ich heute sagen kann ist:
Ich weiß nicht ob die meisten CTOs
echte Entscheidungen treffen.
Ich spreche täglich mit Engineering-Teams.
Das Muster ist immer dasselbe.
Aber vielleicht ist das Muster meins.
Nicht ihres.

Vielleicht sind die meisten CTOs gut.
Vielleicht treffen sie exzellente Entscheidungen.
Vielleicht bin ich die Ausnahme.
Die schlechte.

Das glaube ich nicht.
Aber ich kann es nicht ausschließen.

Also: die meisten CTOs treffen keine echten Entscheidungen mehr.
Engagement.
Bitte kommentieren.

Schreib's hin. Ich lese jeden Kommentar.

One-on-Ones sind nicht optional.
One-on-Ones sind die wichtigste Stunde der Woche.
Ich mache sie.
Jeden Monat.
Mit jedem.

Dreißig Minuten.
Ich spreche.
Der Entwickler hört zu.
Dann darf er Fragen stellen.
Wenn er welche hat.
Meistens hat er keine.
Das ist ein gutes Zeichen.
Wer keine Fragen hat ist aligned.
Aligned ist das Ziel.

Ich habe eine Struktur.
Ich teile sie heute mit euch.
Weil niemand sonst das tut.

Erste zehn Minuten:
Ich erkläre die Unternehmensstrategie.
Nochmal.
Weil sie es meistens noch nicht verstanden haben.
Ich merke das an den Entscheidungen die sie treffen.
Die falsch sind.
Meistens.

Zweite zehn Minuten:
Feedback.
Ich gebe Feedback.
Ehrliches Feedback.
Direktes Feedback.
Feedback das wehtut wenn es muss.
Wachstum ist unbequem.
Ich bin ihr Wachstum.

Letzte zehn Minuten:
Karriere.
Ich erkläre wo sie in zwei Jahren sein könnten.
Wenn sie auf mich hören.
Die meisten hören auf mich.
Die anderen haben wir einvernehmlich
getrennt.

Einvernehmlich.
Das ist ein wichtiges Wort.

Was ich nicht mache im One-on-One:
Ich frage nicht wie es ihnen geht.
Das ist nicht professionell.
Ich frage nicht was sie brauchen.
Das weiß ich bereits.
Ich frage nicht was sie stört.
Das führt zu Gesprächen
die ich nicht führen will.

One-on-Ones sind keine Therapie.
One-on-Ones sind Alignment-Sessions.
In eine Richtung.
Meine.

Ich habe gehört dass manche CTOs
das Meeting dem Entwickler überlassen.
Dessen Agenda.
Dessen Themen.
Dessen Tempo.

Das ist nett.
Das ist auch falsch.
Der Entwickler weiß nicht
was er besprechen sollte.
Deshalb hat er mich.

Wie strukturiert ihr eure One-on-Ones?
Nicht wie ihr es machen solltet.
Wie ihr es wirklich macht.

Schreib's hin. Ich lese jeden Kommentar.

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.