Die Junior und die Senior-Rolle

Table of Contents

Motivation

Als Führungskraft erlebt man immer wieder Spannungen im Team, weil die Erwartungen an eine Rolle oder Position nicht klar definiert sind. Was genau wird von einem Junior erwartet? Woran misst sich eine Senior-Rolle wirklich?

Wenn diese Erwartungen nicht transparent sind, entstehen Missverständnisse – sowohl in der Zusammenarbeit als auch in der persönlichen Weiterentwicklung. Dieser Text soll helfen, die Unterschiede klarer zu machen und Orientierung zu geben.

Disclaimer

Die folgenden Gedanken stammen aus meiner persönlichen Erfahrung in der Softwareentwicklung.
Viele Punkte lassen sich sicher auf andere Disziplinen übertragen, der konkrete Kontext ist jedoch die Arbeit in
Softwareprojekten – mit Code, Ticketsystemen, Deployments und technischen Abhängigkeiten.

Junior

Ehrlich gesagt bin ich kein Fan der Bezeichnung „Junior“. In vielen Betrieben wird dieser Begriff jedoch genutzt, um eine Entry-Level-Rolle zu beschreiben. Dabei geht es weniger um Alter oder gesamte Berufserfahrung, sondern vielmehr um den Fit der Skills zur konkreten Stelle.

Denn egal, wie viel Vorerfahrung jemand aus einer anderen Software-Engineering-Position mitbringt: Jede neue Stelle bietet genügend Herausforderungen, um sich über Wochen oder sogar Monate einarbeiten zu müssen.

Beispiele:

Du hast Erfahrung in Vue 3 – die Firma arbeitet noch mit Vue 2 oder React
Du kennst dich mit CMake aus – das Unternehmen nutzt jedoch Perforce Jam oder natives make.

Je schneller ein Mitarbeiter oder eine Mitarbeiterin den Anforderungen der neuen Rolle gerecht wird und eigenverantwortlich im Tagesgeschäft arbeiten kann, desto eher kann das Attribut „Junior“ abgelegt werden.

Welche Tipps ergeben sich daraus für eine Junior-Rolle?

Kommunikation & Netzwerken

Vermeide es, in deiner Junior-Zeit zum Einzelkämpfer zu werden – Teamwork makes the dream work.

Hilfe suchen – 30-Minuten-Regel

Wenn du nach 30 Minuten konzentrierter Recherche keinen Ansatz oder keine Richtung siehst – frag nach Hilfe.

Hast du zwar einen Ansatz und vielleicht schon ersten Code geschrieben, siehst aber nach zwei bis vier Stunden noch kein Licht am Ende des Tunnels, dann solltest du ebenfalls Unterstützung einholen.

Adressatenkreis beachten

Wähle die richtigen Verteiler / Personenkreis. Wer benötigt diese Information wirklich?

Flughöhe beachten (Detailgrad der Information)

Wenn du den passenden Verteiler identifiziert hast, überlege dir, wie viele Details die Empfänger benötigen. Führungskräfte möchten meist das große Ganze, neudeutsch: Big Picture. Techniker freuen sich auch über Code-Snippets oder technische Details.

Medienbrüche vermeiden

Kommt eine Anfrage per E-Mail, antworte nicht im Chat. Wird ein Thema in einem Ticket eröffnet, führe die Diskussion dort weiter. Wenn ihr aneinander vorbeiredet, greift zum Hörer und klärt Unklarheiten synchron.

Wichtig: Fasse das Ergebnis eines Gesprächs anschließend schriftlich zusammen.

Tasks gliedern – Nächste sinnvolle Schritte erarbeiten und dokumentieren

Als Full-Stack-Developer in einem Webprojekt solltest du ein Feature sauber zerlegen können, zum Beispiel:

Button im Frontend einbauen
API-Endpoint im Backend hinzufügen
Datenbankschema anpassen

Diese Schritte sollten auch im Ticket dokumentiert werden.

Feedback – Frühzeitiges Einbeziehen weiterer Kollegen

Wenn du Schwierigkeiten bei der Zerlegung von Aufgaben hast, frage erfahrene Kollegen, welche Schritte erforderlich
sind.

Auch den Einsatz externer Libraries oder Tools solltest du vorab abstimmen, bevor du tagelang implementierst. Manche
Projekte verbieten bestimmte Technologien, etwa Exceptions oder Introspection/Reflection/RTTI. Auch OSS-Lizenzen wie
GPLv3 oder AGPL können problematisch sein.

Basiswissen über Produkte und Projekte deiner Firma aneignen

Versuche, möglichst viel über die Produkte und Projekte deiner Firma zu lernen. Gibt es Ausstellungen, Demoräume oder Hausmessen? Nutze diese Gelegenheiten und beschäftige dich intensiv mit den Produkten. Benutze Produkte aus der Perspektive der Endanwender.

Code schreiben

Am Anfang ist es oft schwierig, sich in einer neuen Codebasis zurechtzufinden.

Vermeide es, stundenlang nur Code zu lesen. Starte stattdessen – falls vorhanden – einen Unit- oder Komponententest und debugge dich durch die Anwendung. Das ist meist effizienter.

Wenn du grob verstanden hast, was der Code macht, beginne mit kleinen Experimenten. In der Regel steht der Code unter Versionsverwaltung – du kannst also Änderungen vornehmen und sie jederzeit zurückrollen.

Gibt es noch keine Tests, ist das deine Chance, einen ersten Test für den Happy Path zu schreiben.

Du kannst außerdem:

undokumentierte Funktionen mit Docstrings versehen
die Wiki-Seite überarbeiten
Rechtschreibfehler korrigieren oder defekte Links reparieren

All das hilft dir, dich mit dem Projekt vertraut zu machen – und zeigt Proaktivität. „Däumchen drehen“ wird selten
positiv wahrgenommen.

Spekulative Generalisierung vermeiden

„Premature optimization is the root of all evil.“

Nutze beispielsweise die Rule of Three: Implementiere erst zur Generalisierung, wenn du etwas dreimal nahezu identisch implementiert hast. Man sollte nicht zu früh abstrahieren, sondern erst dann, wenn sich ein Muster wirklich bestätigt hat.

Löse die Probleme von heute – nicht die von morgen.

Versionsverwaltung konsequent benutzen

Committe mehrmals am Tag und pushe deine Änderungen spätestens bevor du abends gehst.

Einsatz von AI

Nutze AI-Tools gezielt als Lern- und Sparringspartner.

Lass dir bestehenden Code erklären – insbesondere dann, wenn du dich in einer neuen Codebasis zurechtfinden musst. Du kannst dir außerdem Verbesserungsvorschläge für deinen eigenen Code geben lassen, etwa in Bezug auf Lesbarkeit, Struktur oder mögliche Edge Cases. Wichtig ist jedoch: Vermeide es, große Code-Blöcke generieren zu lassen, die du selbst noch nicht vollständig verstehst.

Senior

Folgende Themen sind aus meiner Sicht entscheidend, um eine Senior-Rolle auszufüllen:

Ownership & Planung

Ownership bedeutet, ein Thema aktiv zu übernehmen – so wie ein Hausbesitzer sich eigenverantwortlich um sein Haus
kümmert. Beispiel: Du bringst den Müll raus, ohne dass dich jemand daran erinnern muss.

Proaktives Handeln

Die Fähigkeit, Themen selbstständig zu identifizieren und anzugehen – ohne explizite Beauftragung.

Beispiel: Du entwickelst an einem Webportal mit nur einem Produktivsystem, während alle lokal entwickeln. Du erkennst, dass ein Staging-System sinnvoll wäre, um vor dem Live-Deployment ausführlicher zu testen und „Works on my machine“-Probleme zu
vermeiden. Also setzt Du ein Staging-System auf.

Den eigenen Standard nicht verhandelbar machen

Arbeitet ihr mit einem Ticketsystem, dann halte dich daran.

Wenn ein Kunde (intern oder extern) dich bittet, einen Bug zu fixen, arbeite nicht einfach „auf Zuruf“. Lass ein Ticket erstellen oder erstelle es selbst im Namen des Auftraggebers.

Kommuniziere gerne per E-Mail, Telefon oder Chat – aber halte wichtige Informationen, Entscheidungen und Anforderungen
im Ticket oder Wiki fest. Bereite diese Kommunikation so auf, dass Du und andere noch nach ein paar Tagen wisst, was gemeint war.

#werschreibtderbleibt

Work Breakdown

Noch stärker als in der Junior-Rolle ist hier die Fähigkeit gefragt, komplexe Arbeitspakete in umsetzbare Unteraufgaben
zu zerlegen. Ich nenne sie gerne Minimum Viable Actions – Aufgaben, die nicht weiter zerlegbar sind.

Warum ist das wichtig?

Gerade wenn man mehrere Projekte betreut, wird man häufig unterbrochen (Task Switching). Wenn die kleinste bearbeitbare
Einheit nicht klar definiert ist, entstehen Reibungsverluste.

Ich habe oft erlebt, dass Projekte stagnieren, weil eine Zuarbeit fehlt und alle warten – obwohl parallel andere Aufgaben erledigt werden könnten.

Deshalb:

Identifiziere minimal umsetzbare Tasks
Suche nach Dingen, die jetzt erledigt werden können
Beantrage Rechte
Bestelle Server
Bereite Dokumentation vor.

Das verkürzt Ticketlaufzeiten erheblich.

Abgeben von realistischen Schätzungen und Deadlines

Eine häufige Aussage ist: „Das schaffe ich in ein bis zwei Tagen.“

Dabei werden externe Abhängigkeiten oft vergessen – etwa die IT-Abteilung oder Kollegen, die noch Zugriffsrechte
freigeben müssen.

Für den Auftraggeber zählt nicht nur die reine Entwicklungszeit, sondern wann das Ergebnis vorliegt.

Der „Teufel ist ein Eichhörnchen“: Der Kollege, der Rechte freigeben muss, ist krank oder im Urlaub. Oder der Chef will noch eine Powerpoint sehen, bevor er Budgets freigeben kann – und aus zwei Tagen werden zwei Wochen.

Solche Risiken sollten in der Planung berücksichtigt und transparent kommuniziert werden.

Kommunikation und Delegation

In der Senior-Rolle geht es weniger darum, alles selbst zu erledigen – sondern darum, dass Dinge erledigt werden.

Aufgaben aktiv abgeben oder „Won’t do“ kommunizieren

Andere in die Lage zu versetzen, Aufgaben zu übernehmen, ist essenziell.

Wenn etwas innerhalb der Deadline nicht realistisch umsetzbar ist, ist es fair, das offen zu kommunizieren: „Das werden wir in diesem Zeitraum nicht schaffen.“

Das gibt dem Auftraggeber die Möglichkeit, Alternativen zu prüfen.

Tasks delegierbar aufbereiten & Erwartungen definieren

Wenn du Aufgaben delegieren willst, müssen sie so vorbereitet sein, dass andere problemlos übernehmen können.
Was für dich selbstverständlich ist, ist für andere – besonders Junior-Developer – nicht immer klar. Deshalb:

Abläufe explizit dokumentieren
Systeminteraktionen beschreiben
Erwartungshaltungen definieren
Idealerweise im Ticket oder Wiki.

Finde eine Balance: Genug Information, damit 80 % der Aufgabe umsetzbar sind – ohne sie faktisch schon selbst erledigt zu haben ( 80/20-Prinzip).

Rechtzeitige Kommunikation & Statusupdates

Für externe Beteiligte muss klar sein:

Wer macht was?
Bis wann?
Welche Blocker gibt es?

Frühzeitige Statusupdates sind kein Zeichen von Schwäche, sondern von Professionalität.

Oft glauben wir, blockiert zu sein, weil Informationen fehlen. Spiegelt man diese Blockade dem Kunden, führt das häufig zu Klarheit oder besseren Alternativen.

Erfahrene Entwickler lernen zudem: Kunden kommen oft mit einem Lösungsansatz – nicht mit dem eigentlichen Problem.

Wenn dieser Ansatz ungeeignet ist, ist es professionell zu sagen: „Wir lösen dein Problem – aber mit einem anderen Weg.“

Einsatz von AI

Verwende AI-Tools gerne intensiv – aber immer als Sparringpartner, nicht als Ersatz für dein Urteilsvermögen. Als Senior liegt dein Mehrwert nicht nur im Schreiben von Code, sondern in Bewertung, Einordnung und Qualitätssicherung.

Beispiele für sinnvollen Einsatz:

Du schreibst den Unit-Test – die AI schlägt eine mögliche Implementierung vor, die du anschließend kritisch reviewst
Du implementierst eine Lösung – die AI generiert zusätzliche Testcases oder ergänzt die Dokumentation
Du lässt dir alternative Lösungsansätze oder Refactorings vorschlagen und vergleichst sie mit deinem eigenen Ansatz
Du sparst Zeit, indem du dir neue Projekte, Module oder wiederkehrende Strukturen bootstrappen lässt.

Wichtig dabei:

Behalte die Architekturhoheit
Hinterfrage generierten Code kritisch
Achte auf Randfälle, Sicherheit und Projektkonventionen
Übernimm nur, was du fachlich vertreten kannst.

Ein praktischer Tipp: Committe Änderungen nach jedem sinnvollen Prompt. So bleiben Experimente nachvollziehbar, und du kannst jederzeit zu einem stabilen Stand zurückkehren.

Fazit

Ein Senior ist oft wie ein Zirkusartist, der mit vielen Bällen – oder auch brennenden Hamstern – jongliert. Idealerweise bleiben alle in der Luft und fallen nicht herunter.

Wenn du in einem Thema blockiert bist, solltest du an einem anderen minimalen Task weiterarbeiten können. So entsteht kontinuierlicher Fortschritt – auch bei Abhängigkeiten.

Drei Bücher, die mir geholfen haben

The 7 Habits of Highly Effective People – Stephen R. Covey
Extreme Ownership – Jocko Willink
Die Gesetze der Gewinner – Bodo Schäfer

(Amazon Affiliate Links)