Die Entwicklerwelt liebt ihre Hierarchien und Titel, doch der Übergang vom Junior- zum Senior-Developer ist selten eine Frage der Jahre an Berufserfahrung oder der Anzahl beherrschter Frameworks. Wie das YouTube-Channel „Programmieren Starten“ in einem aktuellen Video auf den Punkt bringt, liegt der fundamentale Unterschied in einer einzigen Kernkompetenz: der Composition – der Fähigkeit, große Probleme in kleine, handhabbare Teilprobleme zu zerlegen.
Die Junior-Falle: Wenn Tippen als Lösung gilt
Das typische Szenario ist aus vielen Teams bekannt: Ein Junior-Developer erhält die Aufgabe, ein Login-System mit Passwort-Reset-Funktionalität zu bauen. Was passiert? Die IDE wird geöffnet, Dateien angelegt und direkt losgetippt. Nach zwei Stunden stellt sich ein Gefühl der Verzweiflung ein. Drei Features wurden angefangen, bei keinem funktioniert der Ansatz richtig, das Code-Chaos ist vorprogrammiert. Der Reset-Button führt zum Neustart des gesamten Projekts.
Das Problem dabei ist nicht mangelndes Code-Wissen. Die Syntax beherrscht der Junior meistens sehr wohl. Das eigentliche Problem ist das Überspringen der Verstands-Phase. Wer das Problem nicht vollständig durchdringt, bevor die erste Zeile Code geschrieben wird, baut keine Lösungen, sondern nur Symptome ab – oder schafft gleich neue.
Der Senior-Ansatz: Stift statt Tastatur
Ein Senior-Developer geht fundamental anders vor. Die erste Amtshandlung ist nicht das Öffnen der IDE, sondern das Greifen nach Stift und Papier. Das große, unübersichtliche Problem („Baue ein Login-System“) wird systematisch dekonstruiert:
- Was genau speichert das User Model?
- Wie wird das Passwort gehasht (Passwort Hashing)?
- Wie sieht der Reset-Flow im Detail aus?
- Wie wird die E-Mail versendet und wie muss der generierte Link beschaffen sein?
- Welche Error States können auftreten und wie werden sie behandelt?
Aus einem monolithischen Block werden so sechs klar definierte Miniprojekte. Noch wichtiger: Es lässt sich nun eine logische Reihenfolge festlegen. Es macht keinen Sinn, den Passwort-Reset zu coden, bevor die Foundation (User Model, Hashing) und der Zugang (Session, Error States) stehen. Wenn der Senior-Developer schließlich zur Tastatur greift, schreibt sich der Code fast von selbst, weil die Logik im Vorfeld bereits lückenlos durchdacht wurde.
Die Illusion der sichtbaren Arbeit
Warum tun sich Junioren so schwer mit diesem Ansatz? Das Video bringt ein essenzielles Mindset-Problem auf den Punkt: Denken sieht nicht nach Arbeit aus. Es produziert keine Zeilen Code, keine Commits, keinen sichtbaren Output. In einer Branche, die oft nach Output und Velocity bemessen wird, fühlt sich Planen und Nachdenken für viele wie Faulheit an.
Doch es gibt sichtbare und unsichtbare Arbeit – und beides ist echte Arbeit. Das Abarbeiten von Tickets mag im Kanban-Board gut aussehen, aber die eigentliche produktive Kraft entfaltet sich in der unsichtbaren Phase: Subprobleme verstehen, falsche Annahmen verwerfen, Abhängigkeiten erkennen und eine saubere Reihenfolge planen. Das ist die eigentliche Entwicklerarbeit. Code niederzuschreiben, ist im Vergleich dazu der einfache Teil.
Kritische Einordnung: Systemisches Problem statt individuelles Versagen
Die Beobachtung aus dem Video ist treffend, doch man muss die Perspektive erweitern: Das „Direkt-Lostippen“ von Junioren ist oft nicht nur ein persönlicher Mindset-Fehler, sondern auch ein systemisches Problem. In vielen Unternehmen herrscht ein ungesunder Druck, schnell sichtbare Ergebnisse zu liefern. „Look busy“-Kultur und enge Sprint-Zyklen lassen wenig Raum für die unsichtbare Arbeit der Problemdurchdringung. Senioren können sich den Luxus der Planung oft nur erlauben, weil sie sich auf ihre Erfahrung berufen können, während Junioren aus Angst vor Ineffizienz-Vorwürfen sofort in Aktionismus verfallen. Unternehmen müssen kulturell vermitteln: Planung ist kein Zeitverlust, sondern das Fundament sauberen Codes.
Zudem ist Composition zwar der Schlüsselskill, aber er funktioniert nur in Verbindung mit der Bereitschaft, das eigene Denken kritisch zu hinterfragen. Ein nützlicher Tipp aus dem Video ist das „Laut-Denken“ (oder Rubber Ducking): Wenn man beim lauten Erklären eines Problems ins Stocken gerät, hat man die Lücke im eigenen Verständnis gefunden.
Besonders beim Debuggen zeigt sich der Unterschied: Ein Junior fixiert das Symptom („Login schlägt bei Sonderzeichen fehl“), ein Senior prüft die Annahme („Ich ging davon aus, Passwörter sind reine ASCII-Zeichenketten – diese Annahme war falsch“). Symptome zu fixen ist schnell, Annahmen zu prüfen ist Senior-Level.
Fazit
Wer vom Junior zum Senior aufsteigen will, muss aufhören, seinen Wert an Zeilen Code oder Tippgeschwindigkeit zu messen. Der nächste Task sollte nicht mit der IDE, sondern mit einem Blatt Papier und zehn Minuten ungestörtem Nachdenken beginnen. Die Aufgabe in eigene Worte fassen, Subprobleme identifizieren und eine Reihenfolge definieren – wer sich diese Routine aneignet, hat den wichtigsten Schritt auf dem Weg zum Senior-Developer bereits getan.
Quelle: Programmieren Starten
