Hauptgedanke

Eine Kompetenz, die der normale Arbeitsalltag nicht mehr fordert, erhält sich nicht von selbst. Ein Entwickler, der einen Assistenten bittet, an seiner Stelle zu lesen, zu erklären und zu korrigieren, behält das Geschick, das Werkzeug zu steuern, und verliert nach und nach die Fähigkeit, unbekannten Code zu lesen, eine Diagnose durchzuhalten oder eine Architektur zu vereinfachen.

Die Abhilfe besteht nicht darin, auf das Werkzeug zu verzichten, sondern Situationen zu schaffen, in denen es nicht zur Verfügung steht: Dojos ohne Assistent, Übungen mit gedrosseltem Assistenten, Reviews, in denen man den Code selbst erklären muss, Momente, die man sich bewusst nimmt, um zu lesen, zu verstehen und zu vereinfachen. Dieselbe Logik akzeptiert man anderswo ohne Diskussion — der Taschenrechner ist nützlich, aber wer nie selbst eine Rechnung aufschreibt, macht sich abhängig; im Sport fügt man Gewicht und Widerstand hinzu, weil es der Widerstand ist, der den Muskel aufbaut.

Das ist keine Nostalgie nach dem Entwickler, der leiden muss, um seinen Beruf zu verdienen, und das Ziel ist nicht, überall langsamer zu werden. Es geht darum, an der richtigen Stelle langsamer zu werden: einen Teil der Zeit sehr schnell produzieren und lange Zeitfenster schützen — einen Tag für kontinuierliche Verbesserung, Architektur-Reviews, ADRs, langsame Refactorings, Post-mortems misslungener Generierungen —, um zu verstehen, was produziert wurde.

Warum das wichtig ist

Das schließt eine Lücke, die keine Produktionsregel abdeckt: Die Gegenmaßnahmen, die die Qualität des Systems schützen, schützen nicht die Fähigkeiten derer, die es verantworten. Ein Team kann eine tadellose Merge-Disziplin pflegen und dabei die Kompetenz verkümmern lassen, mit der es beurteilen könnte, was es mergt.

Es liefert auch eine Lesart für ein Problem, das älter ist als die Werkzeuge: Viele Entwickler steckten schon vorher im Tagesgeschäft fest und produzierten, ohne den Abstand zu gewinnen, durch den man dazulernt. Die Beschleunigung verschärft diese Schieflage, wenn sie den gesamten frei gewordenen Raum mit noch mehr Produktion füllt, und behebt sie, wenn sie dazu dient, die Zeit des Machens von der Zeit des Verstehens zu trennen.

Nuancen und Grenzen

Die hinzugefügte Schwierigkeit muss der des echten Berufsalltags ähneln. Eine künstliche Übung trainiert die Routine in der Übung, nicht die angestrebte Kompetenz — und eine schlecht gewählte Einschränkung kostet Zeit, ohne etwas zu lehren.

Und manche überflüssig gewordenen Kompetenzen dürfen verschwinden: Niemand übt Assembler, um bei seinem eigenen Code den Überblick zu behalten. Zu unterscheiden, was man pflegen muss und was man aufgeben kann, ist eine offene Abwägung, die dieser Gedanke nicht entscheidet.

Offene Fragen

• Woran merkt ein Team, dass eine Kompetenz erloschen ist, während seine tägliche Produktion sie schon lange nicht mehr gefordert hat und normal wirkte?