Junior-Entwickler:innen anleiten: ein Leitfaden für Seniors, die noch nie Mentor:in waren

Die meisten Senior-Entwickler:innen werden Mentor:innen, ohne dass ihnen jemand sagt, wie das geht. Ein Junior kommt ins Team, Sie kennen die Codebasis am besten, und die Aufgabe landet bei Ihnen. Der erste Impuls ist, die Probleme schnell selbst zu lösen. Es ist auch der Impuls, bei dem der Junior am wenigsten lernt.

Etwas zu können und es beizubringen sind zwei verschiedene Dinge. Die folgenden Gewohnheiten würde ich einem Senior geben, der zum ersten Mal mentort. Keine davon braucht ein Schulungsbudget.

1. Entscheiden, was Sie vermitteln

„Ihm helfen, besser zu werden“ ist zu vage, um danach zu handeln. Wählen Sie zwei oder drei konkrete Dinge für das nächste Quartal und vereinbaren Sie sie mit dem Junior. Meist gehören sie zu einer von drei Arten:

• Fähigkeiten: Tests schreiben, den Debugger benutzen, einen Stacktrace lesen, eine verständliche Commit-Nachricht formulieren.
• Wissen: wie das System zusammenhängt, warum das Datenmodell so aussieht, wie das Deployment funktioniert.
• Entscheidungsfähigkeit: wann man um Hilfe bittet, wann eine Abkürzung vertretbar ist, wie man eine Aufgabe zerlegt.

Fähigkeiten lassen sich üben, Wissen lässt sich erklären, und Entscheidungsfähigkeit lässt sich nur vormachen und besprechen. Mentor:innen, die Entscheidungen wie Fakten behandeln („mach das immer so“), erziehen Juniors, die Regeln befolgen, ohne sie zu verstehen.

2. Den Grund erklären, nicht nur die Korrektur

Vergleichen Sie zwei Review-Kommentare zur selben Zeile:

Nimm hier Promise.all.

Diese beiden Requests hängen nicht voneinander ab, sie könnten also parallel laufen. Mit Promise.all wartet man nur noch auf den langsameren. Würde das auf dieser Seite helfen?

Der erste Kommentar bringt den Code in Ordnung. Der zweite bringt die nächsten hundert ähnlichen Fälle ohne Sie in Ordnung. Er kostet einen Satz mehr.

Einige Gewohnheiten machen Review-Kommentare lehrreich:

• Kennzeichnen Sie Kleinigkeiten mit nit: und sagen Sie klar, welche Kommentare den Merge blockieren. Juniors behandeln sonst jeden Kommentar als Anweisung.
• Stellen Sie eine Frage, wenn Sie unsicher sind, und stellen Sie etwas fest, wenn Sie sicher sind. Beides zu vermischen („vielleicht könntest du eventuell …“) verbirgt, was Sie meinen.
• Sagen Sie, was gut ist. Wer etwas Gelungenes benennt, zeigt, was man wiederholen soll.
• Überlassen Sie Stilfragen dem Formatter und dem Linter, damit Ihre Kommentare vom Entwurf handeln.

3. Sie ringen lassen, mit Zeitlimit

Debuggen lernt man durch Debuggen. Wenn Sie die Antwort innerhalb einer Minute liefern, lernt der Junior, dass Sie der Debugger sind.

Wer dagegen einen ganzen Nachmittag feststeckt, ohne es zu sagen, lernt nichts und verliert einen Tag. Eine Regel, die beiden Seiten gerecht wird: 30 bis 45 Minuten allein versuchen, dann fragen, und mitbringen, was man probiert hat. Sagen Sie das am ersten Tag laut, und sagen Sie dazu, dass Nachfragen danach erwartet wird und keine Schwäche ist.

Wenn jemand fragt, gehen Sie eine Leiter hinauf, statt direkt die Antwort zu geben:

1. Fragen Sie, was bereits probiert wurde und was passieren sollte.
2. Zeigen Sie auf den Bereich: „Schau dir an, was die Antwort vor dieser Zeile enthält.“
3. Zeigen Sie eine Technik: „Setz hier einen Breakpoint und sieh dir den Wert an.“
4. Erst dann zeigen Sie die Lösung und lassen sie sich erklären.

4. An den schwierigen Stellen zusammen arbeiten, der Junior an der Tastatur

Pairing ist der schnellste Weg, die eigene Arbeitsweise weiterzugeben: wie Sie sich im Code bewegen, wonach Sie suchen, wie Sie entscheiden, was als Nächstes zu probieren ist. Es ermüdet auch beide, setzen Sie es also dort ein, wo es sich lohnt: bei der ersten Aufgabe in einem neuen Bereich, bei einem kniffligen Bug, bei einem Entwurf, der noch unklar ist.

Der häufigste Fehler ist, die Tastatur zu übernehmen. Wenn Sie es nicht aushalten, wie langsam der Junior tippt, ist genau das die Stelle, die geübt werden muss. Bitten Sie ihn, laut zu denken, und halten Sie die Hände weg, solange er nicht darum bittet.

5. Echte Aufgaben mit Sicherheitsnetz geben

Ein Junior, der nur Übungen bekommt, bleibt ein Junior. Geben Sie ihm ein kleines Stück echter Arbeit: einen Bug im Produktivcode, ein kleines Feature hinter einem Feature-Flag, ein Refactoring mit guten Tests drumherum. Prüfen Sie es sorgfältig und sorgen Sie dafür, dass ein Fehler keine Kunden trifft.

Klären Sie, wem das Ergebnis gehört. Gehört es ihm, schreiben Sie es nicht nachts heimlich um. Der Review-Kommentar ist der richtige Weg.

6. Fehler melden sicher machen

Das Teuerste, was ein Junior tun kann, ist, einen Fehler zwei Tage lang zu verschweigen. Er wird es tun, wenn es beim letzten Mal schlecht ausging. Fragen Sie bei einem Ausfall, was das System zugelassen hat, nicht, wer es war. Und erzählen Sie von Ihren eigenen Fehlern, auch den unspektakulären. So wird deutlich, dass Fehler zum Beruf gehören.

7. Sich regelmäßig treffen und konkretes Feedback geben

Ein wöchentliches Gespräch von 30 Minuten schlägt das Jahresgespräch. Nutzen Sie es für drei Dinge: was gut lief, wo er feststeckte und was er als Nächstes lernen möchte. Feedback wirkt, wenn es konkret ist und zeitnah kommt: „Im gestrigen Pull Request hast du die Arbeit in drei kleine Commits aufgeteilt. Das hat das Review leicht gemacht“ ist nützlich. „Gut gemacht“ ist es nicht.

Für Kritik beschreiben Sie die Situation, was Sie gesehen haben und die Wirkung: „Im Standup hast du gesagt, die Aufgabe sei fast fertig, und am Donnerstag stellte sich heraus, dass es zwei Tage Arbeit waren. Ich möchte früher erfahren, wenn etwas größer ist als erwartet.“

Was Seniors oft falsch machen

Gewohnheit	Warum sie schadet	Stattdessen
Den Code des Juniors umschreiben	Er sieht nie, was falsch war und warum	Kommentieren, ihn selbst ändern lassen
Eigene Vorlieben als Regeln lehren	Er unterscheidet Geschmack nicht von Korrektheit	„Ich bevorzuge“ sagen und den Grund nennen
Nicht erreichbar sein	Er hängt fest und verschweigt es	Eine feste tägliche Zeit für Fragen
Schweigen für Verständnis halten	Juniors sagen selten „ich verstehe das nicht“	Sich das Gesagte erklären lassen
Alles vorab erklären	Zu viel, um es zu behalten	Das beibringen, was die nächste Aufgabe braucht

Woran Sie merken, dass es funktioniert

Der Maßstab ist nicht, wie viel Code der Junior schreibt. Der Maßstab ist, wie oft er Sie für dieselbe Art von Problem braucht. Nach drei Monaten sollte er andere Fragen stellen, solche, die eher den Entwurf betreffen als die Syntax. Wenn das so ist, geben Sie ihm schwierigere Aufgaben und treten Sie noch ein Stück zurück. Ihre Aufgabe ist es, absichtlich weniger gebraucht zu werden.