Mentoring und technische Dokumentation
Entwickeln Sie Junior-Teammitglieder durch Pair Programming und zeitnahes Feedback weiter, schreiben Sie ADRs für Architekturentscheidungen und pflegen Sie eine lebende Dokumentation, der andere vertrauen.
Mentoring und technische Dokumentation ist eine kostenlose Frontend Academy-Lektion auf CoddyKit. Dies ist Lektion 3 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Frontend Academy-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Frontend Academy-Kurs umfasst insgesamt 4 Lektionen.
Senior zu sein bedeutet, andere stärker zu machen
Auf Senior-Level besteht Ihre Aufgabe nicht darin, den meisten Code zu schreiben, sondern Ihr Team besser zu machen. Unterstützen Sie Junior-Entwickler, schreiben Sie Dokumentation, die Ihr Wissen multipliziert, führen Sie lehrreiche Code-Reviews durch und gestalten Sie die Architektur so, dass andere schnell und sicher vorankommen.
Durch Pair Programming mentoren
Pair Programming ist der schnellste Weg, einen Junior-Entwickler weiterzuentwickeln. Arbeiten Sie zusammen (oder teilen Sie Ihren Bildschirm) und lassen Sie die andere Person steuern, während Sie navigieren. Vermeiden Sie es, die Kontrolle zu übernehmen – erklären Sie Ihr Denken und stellen Sie sokratische Fragen.
Herausforderungen in der richtigen Größe
Geben Sie Junior-Entwicklern Aufgaben, die knapp über ihren aktuellen Fähigkeiten liegen. Zu leicht = kein Wachstum. Zu schwer = Überforderung und Frustration. Finden Sie das richtige Maß: „Ich glaube, Sie schaffen das mit etwas Unterstützung – gerne können wir gemeinsam daran arbeiten, wenn Sie nicht weiterkommen.“
Code-Reviews als Lehrmethode
Erklären Sie bei PRs von Junior-Entwicklern hinter jedem nicht trivialen Kommentar auch das Warum. Verlinken Sie relevante Dokumentation, frühere PRs oder Artikel. Schlechtes Review: „Verwenden Sie useCallback“. Gutes Review: „Diese Funktion wird bei jedem Rendern neu erstellt – wenn Sie sie an ein memo'd Child übergeben, verursacht das unnötige erneute Rendern. useCallback memoisiert sie. Hier ist ein Beispiel-PR, in dem wir das so gemacht haben: #1234“.
Architectural Decision Records (ADRs)
Ein ADR dokumentiert eine wichtige Architekturentscheidung: was wir entschieden haben, warum, welche Alternativen wir betrachtet und welche Kompromisse wir akzeptiert haben. Ihr zukünftiges Ich wird es Ihnen danken.
# ADR-0007: Use TanStack Query for server state
Date: 2026-05-01
Status: Accepted
## Context
We currently scatter useEffect+fetch+useState patterns across the app.
Cache invalidation is inconsistent, race conditions cause stale data.
## Decision
Adopt TanStack Query (@tanstack/react-query v5) for all server state.
## Consequences
+ Built-in caching, deduplication, optimistic updates.
+ Standard pattern across team.
- Adds ~13KB gzipped.
- Team needs to learn query keys conventions.
## Alternatives Considered
- SWR: smaller, but fewer features (no mutations).
- Apollo Client: overkill (we don't use GraphQL).
- Custom hook: doesn't solve cache invalidation.
## References
- React Query docs: ...Wo ADRs liegen
Speichern Sie ADRs im Repository unter docs/adr/ und nummerieren Sie sie fortlaufend. Sie liegen neben dem Code, den sie beschreiben. Tools: adr-tools, log4brains für eine durchsuchbare Weboberfläche.
README-Qualität
Jedes Package, jede Library und jedes größere Feature benötigt eine README. Fügen Sie Folgendes hinzu: was es tut, wie es installiert wird, wie es verwendet wird (mit Codebeispielen), wie man dazu beiträgt, wie Tests ausgeführt werden und wie man Fehler untersucht. README-getriebene Entwicklung: Schreiben Sie zuerst die README und entwickeln Sie anschließend gemäß dieser Spezifikation.
Inline-Codekommentare – wann Sie sie verwenden sollten
Kommentare sollten das Warum erklären, nicht das Was. Der Code zeigt, was passiert. Kommentare erklären: Geschäftsregeln, nicht offensichtliche Abwägungen, Links zu Tickets oder Bugs und Warnungen vor Fallstricken.
// BAD: comment restates the code
// Increment counter by 1
counter++;
// GOOD: comment explains business context
// Stripe webhook can arrive twice — increment only if signature is fresh.
// See: https://stripe.com/docs/webhooks/best-practices#idempotency
if (!seen.has(event.id)) counter++;Runbooks für operative Aufgaben
Dokumentieren Sie wiederkehrende oder riskante operative Aufgaben: „So rotieren Sie den Stripe API-Schlüssel“, „So beheben Sie einen fehlgeschlagenen Deploy“, „So untersuchen Sie eine langsame API-Antwort“. Neue Teammitglieder können den Anleitungen folgen, ohne Sie alarmieren zu müssen.
Lebendige Dokumentation
Veraltete Dokumentation ist schlimmer als gar keine. Versehen Sie sie mit einem Datum. Überprüfen Sie sie vierteljährlich. Löschen Sie Dokumentation, die niemand aktualisiert. Noch besser: Generieren Sie Dokumentation aus dem Code (Storybook für Komponenten, TypeDoc für APIs, OpenAPI für Endpunkte).
Tech-Talks und Brown-Bags
Halten Sie für Ihr Team 20–30-minütige Vorträge über Dinge, die Sie gelernt haben: eine neue Library, eine Debugging-Geschichte oder ein nützliches Muster. Das zwingt Sie, Ihre Gedanken zu ordnen, und vermittelt sie anderen.
Psychologische Sicherheit schaffen
Junior-Entwickler, die Angst haben, Fragen zu stellen, entwickeln sich nicht weiter. Machen Sie „Ich weiß es nicht“ zur Normalität. Schaffen Sie eine Umgebung, in der Fehler erlaubt sind – feiern Sie das Postmortem, nicht die Schuldzuweisung. Als Senior bestimmen Ihre Reaktionen den Ton im Team.
Die Falle des heroischen Codens
Seien Sie nicht die Person, die jeden Produktionsvorfall allein behebt. Dokumentieren Sie die Lösung, arbeiten Sie beim nächsten Mal mit einem Teammitglied zusammen und automatisieren Sie die Diagnose. Ein Team, das Ihre Heldentaten braucht, ist fragil.
Schnelltest
Was ist der Hauptzweck eines Architectural Decision Record (ADR)?
Zusammenfassung: Mentoring und Dokumentation
Senior bedeutet, andere stärker zu machen, nicht den meisten Code zu schreiben. Arbeiten Sie im Pair Programming; lehren Sie durch Code-Reviews; geben Sie Herausforderungen in der richtigen Größe. ADRs unter docs/adr/ halten fest, warum Entscheidungen getroffen wurden. Für jedes Package eine README. Kommentare erklären das Warum, nicht das Was. Runbooks für operative Aufgaben. Lebendige Dokumentation (Storybook, TypeDoc, OpenAPI) ist besser als statisches Markdown. Schaffen Sie psychologische Sicherheit. Vermeiden Sie heroisches Coden.
Häufig gestellte Fragen
Ist die Lektion „Mentoring und technische Dokumentation“ kostenlos?
Ja — der vollständige Text von „Mentoring und technische Dokumentation“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Frontend Academy-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Frontend Academy-Kurs umfasst insgesamt 4 Lektionen.
Was lerne ich in „Mentoring und technische Dokumentation“?
Entwickeln Sie Junior-Teammitglieder durch Pair Programming und zeitnahes Feedback weiter, schreiben Sie ADRs für Architekturentscheidungen und pflegen Sie eine lebende Dokumentation, der andere vert… Du übst Frontend Academy mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.
Brauche ich Erfahrung, um Frontend Academy zu starten?
Keine Vorkenntnisse erforderlich. Frontend Academy auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 3 von 4.
Wie lange dauert die Lektion „Mentoring und technische Dokumentation“?
Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.
Kann ich in dieser Frontend Academy-Lektion Code schreiben und ausführen?
Ja. Jede Frontend Academy-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.
Alle Lektionen in diesem Kurs
- Systemdesign-Interviews für Frontend-Entwicklung
- Code-Review-Kultur und Best Practices für PRs
- Mentoring und technische Dokumentation
- Auf dem Laufenden bleiben: Spezifikationen und Vorschläge lesen