In meinem ersten Jahr habe ich 212 Fragen gestellt. Ich weiß das, weil ich sie mitgeschrieben habe — nicht aus Ordnungsliebe, sondern weil ich nach drei Monaten das Gefühl hatte, ich frage zu viel, und prüfen wollte, ob das stimmt. Es stimmte nicht. Von den 212 waren ungefähr dreißig Fragen, die ich mir in zehn Minuten selbst hätte beantworten können. Die anderen waren der Grund, warum ich nach einem Jahr Code reviewen durfte.


Die Zahl ist nicht der Punkt. Der Punkt ist, dass ich sie aufgeschrieben habe, weil ich sie nicht mehr sehen konnte. Und dass ich beim Durchzählen gemerkt habe: Die Fragen, bei denen ich mich schlecht gefühlt habe, waren meistens die richtigen.


Drei Sorten Fragen

flowchart TD Q["Frage im Kopf"] --> Q1["in 10 Minuten selbst pruefbar?"] Q1 --> P["pruefen, Ergebnis notieren"] P --> P1["gefunden?"] P1 --> P2["weiterarbeiten"] Q --> Q2["steht es in README, ADR oder Issue?"] Q2 --> L["lesen"] L --> L1["fehlt es dort?"] L1 --> L2["ergaenzen"] Q --> Q3["braucht Kontext, den nur ein Mensch hat?"] Q3 --> F["Frage mit Vermutung und Frist stellen"] Q3 --> A["Antwort aufschreiben, nicht nur merken"]

Die dritte Sorte ist die, für die man sich entschuldigt, und die einzige, die man nicht selbst beantworten kann. „Warum ist dieser Retry so eingestellt?" steht in keinem Repository. Es gibt eine Person, die es weiß, und die Antwort ist meistens eine Geschichte über einen Vorfall von vor zwei Jahren. Solche Fragen sind kein Zeichen von Unwissen. Sie sind der einzige Weg, Geschichte nachzuladen.


Das Fragen-Budget

Irgendwann habe ich angefangen, Fragen wie ein Budget zu behandeln: nicht unbegrenzt, aber auch nicht null. Meine Regel war eine pro Person und Tag, und wenn ich mehr brauchte, habe ich gesammelt und in einem Block gestellt. Nicht weil die Personen knapp sind, sondern weil eine gesammelte Frage billiger zu beantworten ist als fünf einzelne — für beide Seiten.


Symbolbild: KI-generiert für diesen Artikel (Flux).

Was ich dabei gelernt habe: Das Budget war nie der Engpass. Der Engpass war mein Kopf, der jede Frage als Belastung gebucht hat. Das Team hat anders gerechnet: Eine Frage, die verhindert, dass ich zwei Tage in die falsche Richtung laufe, ist die billigste Investition des Tages.


Wie man fragt, ohne zu blockieren

Meine erste Version war: „Hallo, kannst du mir kurz helfen?" Diese Frage kostet die andere Person einen Kontextwechsel, bevor sie überhaupt weiß, worum es geht. Sie ist höflich und teuer. Meine zweite Version war besser:


Kurz: Migration bricht lokal bei Schritt 3 ab.

Probiert:
- npm run db:reset (gleicher Fehler)
- Postgres lokal statt Container (gleicher Fehler)

Vermutung: Migration 004 erwartet eine Spalte, die der Seed nicht setzt.

Frage: gibt es einen Grund, warum 004 keine Default-Werte setzt?

Ich arbeite bis 16:00 weiter, danach brauche ich eine Antwort
oder ich nehme einen anderen Task.

Fünf Angaben: was passiert, was ich probiert habe, was ich vermute, was ich wissen will, bis wann. Das spart der anderen Person die Rückfrage „hast du schon X probiert", und diese Rückfrage ist das eigentliche Kostenproblem an einer schlechten Frage.


Der letzte Satz ist der wichtigste. Eine Frage ohne Frist blockiert dich und die andere Person gleichzeitig, weil keiner weiß, wie dringend es ist. „Ich kann bis 16:00 weiterarbeiten" sagt: Es ist nicht dringend, aber es ist auch nicht egal.


Die Frage, die niemand stellt

Die teuerste Frage ist die, die nicht gestellt wird. Bei mir war es eine Deploy-Reihenfolge: Ich habe angenommen, dass ein Job vor dem Deploy läuft, weil er in der Dokumentation zuerst stand. Er lief danach. Zwei Stunden später war eine Tabelle leer, die nicht leer sein sollte, und ich habe vierzig Minuten in der falschen Richtung gesucht, weil ich eine Frage nicht stellen wollte, die nach Basiswissen klang.


Ich habe danach eine Regel eingeführt, die ich immer noch benutze: Wenn ich eine Annahme treffe, die ich nicht in zwei Minuten prüfen kann, schreibe ich sie in den Pull Request. Nicht als Frage, nur als Satz. Ich gehe davon aus, dass der Job vor dem Deploy läuft. In neun von zehn Fällen antwortet jemand mit einem Daumen. Im zehnten Fall antwortet jemand mit „nein, seit dem Umbau nicht mehr" — und das ist die Antwort, für die man Fragen stellt.


Diese Sätze kosten mich zehn Sekunden pro Pull Request. Sie sind auch der Grund, warum ich beim Review inzwischen anders lese: Ich suche nicht mehr nach Fehlern, sondern nach Annahmen, die niemand aufgeschrieben hat. Die Fehler kommen danach von selbst.


Symbolbild: KI-generiert für diesen Artikel (Flux).

Was mir dabei geholfen hat, war eine Zahl aus einem Gespräch mit einer Kollegin: Sie schätzt, dass sie in ihrer ersten Zeit im Schnitt zwei Stunden pro Woche damit verliert, Dinge selbst herauszufinden, die ein Satz geklärt hätte. Zwei Stunden sind kein Notfall. Zwei Stunden pro Woche, ein Jahr lang, sind zehn Arbeitstage, die niemand sieht und niemand bezahlt.


Fazit

Fragen sind kein Defizit, sie sind ein Messinstrument: Sie zeigen, wo Dokumentation fehlt, wo Annahmen im Team auseinanderlaufen und wo jemand seit Wochen dasselbe rät. Der Preis, nicht zu fragen, sind zehn Arbeitstage im Jahr und ein Selbstbild, das mit jedem Tag ein bisschen schlechter wird. Der Preis, gut zu fragen, sind fünf Sätze und die Disziplin, die Antwort aufzuschreiben. Ich habe 212 Mal geübt. Es wird langsam.


Ich habe 212 Fragen aufgeschrieben und dreißig davon hätten warten können: Welche Frage hat bei euch zuletzt eine fehlende Zeile im README aufgedeckt?