Idee

Einen Code-Assistenten zu führen, verlangt die Arbeit eines Mentors für Junior-Entwickler, ohne den Lernfortschritt, durch den sie sich lohnt

Info

Ursprünglich auf Französisch verfasst. Von KI übersetzt — der Sinn wurde bewahrt, nicht der Stil.

Hauptgedanke

Die Führungsarbeit ist dieselbe, die ein erfahrener Entwickler bei einem Berufseinsteiger leistet: noch einmal erklären, warum eine Datei nicht alles enthalten darf, warum eine Schicht eine andere nicht kennen soll, warum man nicht die kompletten Daten lädt, warum man Tests schreiben und warum man sie erneut laufen lassen muss. Man gibt einen Screenshot einer Komponente, und zurück kommt eine vereinfachte Deutung, die man nacharbeiten muss.

Anders ist, was dieser Aufwand einbringt. Einen Junior anzuleiten, ist eine Investition: Dieselben Hinweise wiederholen sich nicht endlos, weil die Person dazulernt. Ein Assistent lernt von sich aus nichts dazu – die Korrektur gilt für die Sitzung, nicht für die nächste, und dieselbe Abweichung kehrt bei der nächsten Funktion wieder.

Die Führung eines Assistenten lohnt sich also nur, wenn sie das Medium wechselt: Was man einem Junior sagen würde, muss einmal in den Rahmen geschrieben werden, den der Assistent jedes Mal liest – Anweisungsdateien, Konventionen, ein Katalog von Mustern. Jedes Mal neu zu erklären, ist der teure Weg; aufzuschreiben ist der Weg, auf dem sich etwas ansammelt.

Warum das wichtig ist

Das korrigiert die spontane Lesart dieser Beziehung. Wer den Assistenten als sehr schnellen Junior beschreibt, zieht daraus meist einen optimistischen Schluss – man muss ihn nur gut führen –, obwohl der Mechanismus verschwunden ist, der die Führung erträglich machte.

Es zeigt auch, wohin die tatsächlich gewonnene Zeit geht: nicht in die Code-Produktion, die wirklich schneller ist, sondern in die Wiederholung einer Führung, die nichts aufbaut, solange nichts sie festhält.

Nuancen und Grenzen

Die Analogie hat Grenzen: Anders als ein Junior wird der Assistent es nicht leid, korrigiert zu werden, verliert kein Selbstvertrauen und kostet keine Karriere. Der Vergleich dient dazu, die Führungslast einzuordnen, nicht dazu, die Beziehung zu beschreiben.

Und das Aufschreiben des Rahmens hat selbst seinen Preis, der sich nur bei wiederholter Arbeit rechtfertigt. Für ein Werkzeug, das an einem Abend gebaut und am nächsten Tag aufgegeben wird, ist wiederholtes Erklären billiger als Aufschreiben.

Offene Fragen

  • Welcher Teil dessen, was ein erfahrener Entwickler einem Junior weitergibt, lässt sich tatsächlich in einer Anweisungsdatei festhalten, und welcher Teil besteht nur im Gespräch über einen konkreten Fall?