Warum wir weiterhin in Mentoring investieren

Beim Schreiben dieses Beitrags wurde keinem Junior-Entwickler eine Leseliste zugeteilt.

Einer unserer Entwickler kämpfte seit Monaten mit derselben Sorte Bug. Flaky Integrationstests, immer ein anderer Test, immer irgendein Timing-Problem. Er war richtig gut darin geworden, sie zu beheben. Schnell, und die PR-Beschreibung erklärte jedes Mal genau, was schiefgelaufen war.

Dann saß ein Senior zwanzig Minuten in einem Screenshare dabei und sagte: Das sind keine flaky Tests, das ist eine gemeinsam genutzte Fixture, in die alles hineinschreibt.

Das war’s, mehr Eingreifen brauchte es nicht. Zwanzig Minuten, ein Satz, und ein Problem, das jeden Monat still und leise die Aufmerksamkeit eines ganzen Sprints verschlungen hatte, existierte nicht mehr.

Der Entwickler hätte ein Modell zu jedem einzelnen dieser Fehler befragen und eine gute Antwort bekommen können. Hat er auch, oft, und die Antworten waren korrekt. Was niemand von sich aus gesagt hätte: dass alle Antworten auf die falsche Frage gingen, weil sonst niemand das Muster über Monate hinweg beobachtet hatte.

Produktiv sein und besser werden sind zwei verschiedene Dinge

Diese Unterscheidung ist in den letzten zwei Jahren verschwommen, und das kommt teuer zu stehen, glauben wir.

Ein Entwickler mit gutem Tooling kann heute echte Arbeit abliefern, ohne viel davon zu verstehen, warum sie funktioniert. Das ist keine Kritik, dafür sind Werkzeuge da. Aber Ausliefern und Wachsen haben sich still voneinander entkoppelt, und ein Team kann beim Output ziemlich lange gesund aussehen, bevor jemandem auffällt, dass sich bei niemandem das Urteilsvermögen weiterentwickelt.

Am deutlichsten sehen wir es in Reviews. Der Code von jemandem ist in Ordnung. Er ist seit einem Jahr in Ordnung. Aber es ist immer dieselbe Art von „in Ordnung“: dieselbe Sorte Problem, auf dieselbe Weise gelöst. Ändert sich das Problem, steckt die Person auf eine Art fest, die ihre PR-Historie nie hätte vermuten lassen.

Output sagt Ihnen, was jemand produziert hat. Er sagt Ihnen fast nichts darüber, was diese Person nächstes Quartal produzieren könnte.

Code-Review ist kein Mentoring

Wir haben das länger geglaubt, als gut war, auch weil es bequem ist, das zu glauben. Review steht ohnehin im Kalender. Ein Senior schaut sich ohnehin die Arbeit eines Juniors an. Nah genug dran, sollte man meinen.

Ist es nicht, aus einem strukturellen Grund: Review sieht das Artefakt, nicht das Denken, das es hervorgebracht hat.

Wenn ein PR existiert, sind die interessanten Entscheidungen längst gefallen. Die drei Ansätze, die in der ersten Stunde verworfen wurden, das falsche mentale Modell, das Ansatz zwei attraktiv aussehen ließ, die Annahme über das Verhalten der Datenbank, die sich als falsch herausstellte, aber diesmal zufällig nichts kaputt gemacht hat. Nichts davon steht im Diff. Sie können nur reviewen, was überlebt hat.

Dabei lohnt es sich gerade, das fehlerhafte Denken zu erwischen, denn es produziert nächsten Monat einen anderen Bug, in einer Datei, die niemand damit in Verbindung gebracht hätte.

Wir reviewen immer noch alles, wir haben nur aufgehört zu erwarten, dass es eine Aufgabe erfüllt, für die es nie gemacht war.

Nach einem blinden Fleck kann man nicht fragen

Der naheliegende Einwand gegen all das ist 2026, dass ein Modell um 2 Uhr nachts verfügbar ist, nie müde, nie herablassend, und mehr über Ihr Framework weiß als irgendjemand in Ihrem Team.

Alles wahr. Wir nutzen diese Werkzeuge ständig. Sie haben den Teil des Lernens, der aus Fragen besteht, nahezu kostenlos gemacht, und das ist ein echter Gewinn. Der Entwickler, der früher bis Montag wartete, um etwas zu fragen, fragt jetzt einfach.

Aber jede einzelne dieser Interaktionen beginnt damit, dass Sie wissen, was Sie fragen müssen. Diese Grenze ist nicht vorübergehend. Ein Modell kann eine Annahme hinterfragen, die Sie ihm vorlegen. Es kann nicht, metaphorisch gesprochen, an Ihrem Schreibtisch vorbeigehen und bemerken, dass Sie seit sechs Monaten etwas Seltsames tun. Es sieht Sie nicht über längere Zeit. Jedes Gespräch beginnt bei null.

Was Entwickler wirklich zurückhält, sind selten Wissenslücken. Es sind Gewohnheiten. Jedes Mal zur selben Abstraktion greifen. Eine bestimmte Art von Aufgabe chronisch unterschätzen. Verstummen, wenn man feststeckt, statt zu fragen, was in einem vollständig remote arbeitenden Team ein viel größeres Problem ist, weil niemand sieht, wie man verstummt.

Nichts davon ist eine Frage, und genau das ist das Problem. Jemand anderes muss es für Sie bemerken.

Alle anderen haben das längst verstanden

Es ist ein wenig seltsam, dass Software Coaching als Nachhilfemaßnahme behandelt.

Kein ernsthafter Sportler hört auf, einen Trainer zu haben, sobald er gut geworden ist. Musiker, die seit dreißig Jahren auf der Bühne stehen, nehmen immer noch Unterricht. In beiden Fällen ist der Coach häufig weniger fähig als die Person, die er coacht, und das ist in Ordnung, denn der Coach muss nicht besser sein. Er muss von außen hinschauen.

Nur die Softwarebranche tanzt hier aus der Reihe. Wir haben eine Kultur gebaut, in der die Bitte um einen Mentor wie ein Eingeständnis wirkt und in der Seniorität stillschweigend bedeutet, dass man so etwas nicht mehr braucht. Unsere erfahrensten Leute schreiben seit 1997 Produktionscode, und sie ziehen aus einer Stunde, in der ihnen jemand bei der Arbeit zusieht, immer noch mehr als aus den meisten Konferenzen.

Innerhalb des Teams ist das inzwischen weitgehend unspektakulär. Es hat eine Weile gedauert, dorthin zu kommen.

Das Feedback von Software ist schlecht kalibriert

Dass das in unserem Feld mehr zählt als in den meisten anderen, liegt auch daran: Die Zeit zwischen einer Entscheidung und ihrer Folge schwankt enorm.

Machen Sie einen Syntaxfehler, wissen Sie es in unter einer Sekunde. Machen Sie einen Architekturfehler, kompiliert er, besteht die Tests, segelt durchs Review, geht live und kostet Sie dann achtzehn Monate später ein Quartal, wenn eine Anforderung kommt, die das Modell nicht aufnehmen kann. Bis dahin hat derjenige, der die Entscheidung getroffen hat, vergessen, dass er sie getroffen hat, und die Verbindung zwischen Ursache und Wirkung ist nicht mehr herzustellen.

Aus Feedback auf dieser Zeitskala kann man nicht lernen. Niemand kann das. Die Schleife ist zu lang und zu verrauscht.

Ein Mentor verkürzt sie künstlich. Er hat die achtzehn Monate schon durchlebt, mehrmals, und kann Ihnen am Dienstag sagen, was Sie sonst erst 2028 herausfinden würden. Mit Weisheit hat das wenig zu tun. Es ist Erfahrung, für die schon jemand anderes bezahlt hat, und es ist so ziemlich das Nützlichste, was ein erfahrener Entwickler weitergeben kann.

Wir haben über die Velocity-Metrik eines Kunden geschrieben, die sein Team kaputt gemacht hat, und das ist derselbe Fehler auf Organisationsebene. Die Konsequenz kam viel zu spät, um noch mit der Entscheidung in Verbindung gebracht zu werden.

Reibung hat eine Funktion

Hier sind wir vorsichtig, denn in die andere Richtung kann man es genauso leicht falsch machen.

Tut sich ein Entwickler schwer, will man ihm instinktiv das Hindernis aus dem Weg räumen. Das geht schneller, es ist nett, und es ist meist der falsche Schritt, denn im Ringen steckt das Lernen. Wer jemandem die Antwort vorsagt, bekommt ein funktionierendes Feature, aber keine neue Fähigkeit.

Die nützliche Variante ist also enger, als sie klingt. Lassen Sie Leute feststecken. Lassen Sie sie nur nicht an etwas hängen bleiben, in dem keine Lektion steckt, oder in einer Richtung, die strukturell aussichtslos ist. Entscheidend ist, ob die Reibung etwas lehrt, und das richtig einzuschätzen ist der größte Teil der Kunst.

Genau hier versagt ein jederzeit verfügbarer Assistent. Er beseitigt Reibung wahllos. Er kann nicht unterscheiden zwischen einem Kampf, der sich lohnt, und einem Yak, das gerade rasiert werden will, weil er nicht weiß, was Sie dieses Jahr lernen sollen.

Braucht das jeder?

Nein, und das sagen wir lieber, als es zu verkaufen.

Wenn Sie gerade erst anfangen, bringen ein gutes Buch und eine Community Sie weiter als ein Mentor, weil die Grundlagen gut dokumentiert sind und Sie noch nicht die spezifischen Lücken haben, die Einzelbetreuung lohnend machen. Wenn Sie eine klar umrissene Frage haben, lesen Sie die Doku. Wenn Sie ein Code-Review wollen, holen Sie sich ein Code-Review.

Mentoring lohnt sich, wenn der Ertrag ein Vielfaches der investierten Zeit ist, und das trifft meist in genau einer Situation zu: Sie machen das beruflich, Sie sind über das Anfängerstadium hinaus, und Sie sind an eine Decke gestoßen, deren Form Sie nicht erkennen können. Der letzte Teil ist das Erkennungszeichen. Wenn Sie benennen können, was Ihnen fehlt, lernen Sie es einfach. Wenn Sie es nicht können und seit einem Jahr auf demselben Niveau feststecken, dann zahlt sich jemand, der von außen zuschaut, an einem einzigen Nachmittag aus.

Was wir tatsächlich tun

Wir haben das bewusst unstrukturiert gehalten, denn jedes formale Mentoring-Programm, das wir von innen gesehen haben, wurde innerhalb von zwei Quartalen zur Kalenderpflicht.

Was es bei Norveon gibt: Niemand arbeitet lange allein an etwas, Pairing passiert standardmäßig statt auf Anfrage, und unser Stand-up ist ausdrücklich kein Status-Meeting, deshalb hört man, wenn jemand zögert. Dieses Zögern ist meist das Signal, dass jemand auf eine Weise feststeckt, die er noch nicht in Worte gefasst hat.

Die andere Hälfte ist, dass wir danach einstellen. Wir sind 14 Leute. Eine einzige Person, die Fragen als Störung behandelt, kann das Lernen im ganzen Team abwürgen, und das überlebt kein Programm. Nichts in einem Prozessdokument wiegt schwerer als die Frage, ob die erfahrenste Person im Raum sichtbar noch dazulernt.

Wir sind übrigens nicht ganz sicher, ob das trägt. Es informell zu halten bedeutet, dass die, die fragen, Mentoring bekommen, und die Stillen lange unbemerkt bleiben können. Ungefähr zweimal im Jahr spricht das jemand an, und wir haben nie eine Lösung gefunden, die nicht zu genau der Kalenderpflicht wird, die wir vermeiden wollten. Bei 14 Leuten fängt man das auf, weil man alle kennt. Wir gehen davon aus, dass das ab einer gewissen Größe nicht mehr funktioniert, und wir wissen nicht, ab welcher.

Das meiste davon ist uns bei der Arbeit an Arheev aufgefallen. Wenn dasselbe Team über einen langen Zeitraum dasselbe Produkt ausliefert, sieht man genau, wer besser wird und wer ein Plateau erreicht hat, während er vollkommen produktiv bleibt. Auf einem Sprint-Board sehen die beiden identisch aus.

Zwei Jahre später sehen sie sich überhaupt nicht mehr ähnlich.

Kein Mentor wurde per Ticket zugewiesen. Ein paar Gespräche dauerten länger als geplant.