Eine Architektur steht nicht in Diagrammen, sondern in den Köpfen der Leute, die den Code schreiben. Eine Architektin, die alles selbst entscheidet und alles selbst prüft, wird zum Engpass, und wenn sie in Urlaub geht, steht die Architektur still. Microsoft rät der Rolle deshalb, den Ton zu setzen: Entscheidungen früh und oft erklären, in Reviews und in kurzen Runden beim Mittagessen, damit das Team selbst Entscheidungen trifft, die zum Ganzen passen. Diese Lektion zeigt, wie das geht: im Gespräch mit einer Person, im Review eines Pull Requests und im Review einer ganzen Architektur.
Fragen statt Antworten
Wenn eine Kollegin fragt „Wo gehört dieser Code hin?“, ist die schnellste Hilfe die Antwort. Die nachhaltigste ist eine Frage, die sie selbst zur Antwort führt. Wer selbst darauf kommt, versteht den Grund und kann ihn beim nächsten Mal ohne Sie anwenden.
Gute Fragen im Mentoring sind offen und führen zu einer Quelle, nicht zu Ihrer Meinung:
- „Welcher Kontext besitzt diese Daten?“ (Lektion 4.2.6)
- „Was passiert, wenn derselbe Befehl zweimal ankommt?“ (Modul 4.6)
- „Welche Regel der Hausordnung gilt hier, und was sagt der Architekturtest dazu?“
- „Wo würdest du nachsehen, wenn du mich nicht fragen könntest?“
- „Was würdest du tun, und was macht dich unsicher?“
Die letzte Frage ist die wichtigste. Sie zeigt, wo das Wissen fehlt, und oft hat die Person die richtige Idee schon und braucht nur Bestätigung.
Fragen sind nicht immer richtig. Antworten Sie direkt, wenn es eilt (ein Ausfall, ein Termin heute), wenn es um Sicherheit geht (ein
Geheimnis im Code bleibt keine Minute länger stehen, als die Frage dauert), wenn die Person ausdrücklich eine Antwort will, oder wenn es nur ein
Faktum ist („Der Parameter heißt @reloadAll.“). Fragen, deren Antwort Sie schon kennen, sind kein Quiz; wer sich abgefragt fühlt, fragt beim
nächsten Mal nicht mehr.