Ich habe Stellenanzeigen gesehen, die einen „Senior Developer mit 3+ Jahren Erfahrung“ suchten. Ich habe „Junior Developers“ gesehen, die Produktionsinfrastruktur betreuten. Ich habe „Senior“ als Titel gesehen, das vergeben wurde, weil jemand länger als fünf Jahre im Unternehmen war — unabhängig davon, ob er in diesen fünf Jahren etwas gelernt hatte oder dieselben Fehler fünf Jahre lang wiederholt hatte.
Und ich habe den umgekehrten Fall gesehen: Entwickler, die nach zwei Jahren mehr verstanden hatten als manche nach zehn. Die komplexere Probleme lösten. Die bessere Architektur entwarfen. Die im Review die entscheidende Frage stellten, die alle anderen übersehen hatten.
Der Unterschied zwischen Junior, Mid und Senior in der Softwareentwicklung ist keine Frage der Jahre. Es ist eine Frage der Denkweise. Und die meisten Unternehmen verstehen das nicht — weil sie Senior als Titel behandeln statt als Kompetenz.
Was ein Junior Developer ist
Ein Junior Developer kann Code schreiben. Das ist die Grundvoraussetzung, und sie ist nicht trivial — aber es ist nur der Anfang.
Junior bedeutet: Du verstehst die Syntax. Du kannst eine Aufgabe erhalten, die klar definiert ist, und du kannst sie implementieren. Du kennst deine Programmiersprache gut genug, um produktiv zu sein. Du kannst Dokumentation lesen und anwenden. Du kannst ein bestehendes Muster erkennen und es an einer neuen Stelle einsetzen.
Was ein Junior Developer nicht kann — und das ist kein Vorwurf, das ist der Ausgangspunkt — ist, die Folgen seiner Entscheidungen über den aktuellen Sprint hinaus zu sehen.
Ein Junior schreibt eine Funktion, die funktioniert. Das ist gut. Aber die Funktion ist vielleicht schwer zu testen, weil die Abhängigkeiten nicht injiziert wurden. Sie ist vielleicht schwer zu lesen, weil die Variablennamen kryptisch sind. Sie ist vielleicht schwer zu ändern, weil sie drei Dinge auf einmal tut, die orthogonal sein sollten. Sie ist vielleicht langsam, weil der Datenbankzugriff in einer Schleife statt als Batch passiert.
Das ist nicht schlimm. Es ist der natürliche Zustand am Anfang. Jeder hat mal eine Schleife geschrieben, die für jeden Eintrag einen eigenen Datenbankaufruf macht. Das Problem beginnt erst, wenn dieser Code in Produktion geht und niemand ihn hinterfragt — oder wenn der Junior nie jemanden hat, der ihm erklärt, warum das ein Problem ist.
Die Denkweise
Ein Junior denkt in Aufgaben. „Implementiere Feature X.“ „Fixe Bug Y.“ „Schreibe Test für Z.“ Die Aufgabe ist klar, die Lösung ist begrenzt, und der Erfolg ist messbar: Läuft es? Ja? Dann ist es fertig.
Das ist nicht falsch. Es ist notwendig. Aber es ist unvollständig. Weil Softwareentwicklung nicht das Schreiben von Code ist. Softwareentwicklung ist das Treffen von Entscheidungen — und Code ist nur die Darstellung dieser Entscheidungen in einer ausführbaren Form.
Ein Junior, der sich entwickelt, beginnt, über den Code hinauszusehen. Er fragt: „Warum machen wir das so?“ Er beginnt, die Architektur zu verstehen, nicht nur die Implementierung. Er beginnt, Trade-offs zu sehen, nicht nur Lösungen. Das ist der Moment, in dem ein Junior aufhört, ein reiner Befehlsempfänger zu sein, und anfängt, ein Denker zu werden.
Was ein Junior braucht
Ein Junior braucht drei Dinge, und die sind alle gleich wichtig:
Mentoring. Nicht „Hier ist die Aufgabe, mach das.“ Sondern „Hier ist die Aufgabe, und hier ist, warum wir sie so lösen, wie wir sie lösen. Und hier sind drei alternative Ansätze, und hier ist, warum wir sie nicht wählen.“ Ein Junior, der nur Aufgaben bekommt, wird schneller. Ein Junior, der Kontext bekommt, wird besser.
Fehler-Raum. Juniors machen Fehler. Das ist nicht nur normal, es ist notwendig. Ein Junior, der keine Fehler macht, ist entweder ein Genie oder er macht keine Fehler, weil er nichts macht, was Fehler erzeugen könnte. Beides ist problematisch. Juniors brauchen Raum, um Fehler zu machen — und sie brauchen jemanden, der die Fehler sieht, bevor sie in Produktion gehen, und sie als Lerngelegenheit nutzt, nicht als Bestrafung.
Klare Aufgaben. Ein Junior sollte keine mehrdeutigen Anforderungen bekommen. Nicht, weil er nicht damit umgehen könnte, sondern weil die Mehrdeutigkeit zu einem Ergebnis führt, das niemand wollte, und das dem Junior das Gefühl gibt, er habe versagt — obwohl die Anforderung versagt hat. Klare Aufgaben sind kein Zeichen von Mikromanagement. Sie sind ein Zeichen von Respekt für die Lernkurve.
Was ein Mid-Level Developer ist
Ein Mid-Level Developer — „Mid“ oder „Professional“ oder wie auch immer die Stufe heißt — ist der Übergang vom Ausführer zum Entscheider. Das ist die wichtigste und am häufigsten missverstandene Stufe.
Mid-Level bedeutet: Du kannst nicht nur Code schreiben. Du kannst Code schreiben, der funktioniert und wartbar ist. Du kannst eine Aufgabe erhalten, die nicht komplett definiert ist, und du kannst die fehlenden Informationen selbst beschaffen. Du kannst Architekturentscheidungen treffen — für deinen Bereich. Du kannst abwägen: „Soll ich das schnell machen oder richtig? Und was bedeutet ‚richtig‘ in diesem Kontext?“
Ein Mid-Level Developer versteht, dass Code nicht nur läuft, sondern auch gelesen wird. Von anderen. Von ihm selbst in sechs Monaten. Er schreibt Code, der kommuniziert. Er kommentiert nicht, was passiert — er kommentiert, warum es passiert. Oder, noch besser, er schreibt Code, der das Warum selbst erklärt.
Die Denkweise
Ein Mid denkt in Systemen. Nicht mehr in einzelnen Aufgaben, sondern in Zusammenhängen. „Feature X braucht eine neue API-Route. Die Route braucht Authentifizierung. Die Authentifizierung muss mit unserem bestehenden Middleware-Stack funktionieren. Die Route wird wahrscheinlich in drei Monaten erweitert werden, also sollte ich die Struktur so anlegen, dass Erweiterungen einfach sind.“
Das ist der Unterschied. Ein Junior sieht die Aufgabe. Ein Mid sieht die Aufgabe und ihre Umgebung.
Ein Mid kann auch Nein sagen. Nicht aus Faulheit, sondern aus professioneller Verantwortung. „Nein, diese Architektur skaliert nicht.“ „Nein, dieser Shortcut wird uns in drei Monaten Probleme machen.“ „Nein, wir sollten das nicht ohne Tests ausliefern.“ Das ist keine Senior-Exklusivität — das ist etwas, das ein Mid können muss, wenn er Senior werden will.
Die gefährliche Zone
Die Mid-Level-Stufe ist die gefährlichste Stufe. Hier passieren die meisten Fehler in der Karriereentwicklung — nicht der Entwickler, sondern des Unternehmens.
Der häufigste Fehler: Ein Mid wird zum Senior befördert, weil er lange genug dabei ist. Nicht weil er Senior-Denke entwickelt hat, sondern weil er drei Jahre Mid war und das Unternehmen eine Beförderung schuldig ist. Das Ergebnis ist ein „Senior“, der wie ein Mid denkt, aber die Autorität eines Seniors hat. Das ist das Rezept für schlechte Architekturentscheidungen mit höherem Impact.
Der zweithäufigste Fehler: Ein Mid wird im Mid-Level festgehalten, weil er „zu wertvoll in seiner aktuellen Rolle ist“. Das ist die Karrierefalle, die am meisten Schaden anrichtet. Ein Mid, der Senior-Arbeit leistet, aber nicht die Anerkennung bekommt, wird entweder gehen oder aufhören, Senior-Arbeit zu leisten. Beides ist ein Verlust für das Unternehmen.
Was ein Mid braucht
Herausforderung. Ein Mid braucht Aufgaben, die ihn an seine Grenzen bringen. Nicht über sie hinaus — das ist Frust — aber an sie heran. Aufgaben, bei denen er nicht sofort weiß, wie er sie löst. Aufgaben, bei denen er recherchieren, abwägen und entscheiden muss. Ein Mid, der nur Aufgaben bekommt, die er im Schlaf löst, entwickelt sich nicht weiter.
Feedback. Echtes Feedback. Nicht „Gut gemacht!“, sondern „Diese Lösung funktioniert, aber sie hat diese drei Probleme: Sie ist schwer zu testen, sie skaliert nicht linear, und sie hat einen Edge Case, den du nicht bedacht hast. Lass uns darüber reden, wie du das beim nächsten Mal erkennst.“
Autonomie. Ein Mid sollte eigene Entscheidungen treffen dürfen. Nicht alle — aber einige. Er sollte Architekturentscheidungen treffen und dann im Review lernen, ob die Entscheidung gut war. Er sollte Code-Reviews durchführen — nicht nur empfangen. Er sollte an Design-Diskussionen teilnehmen, nicht nur zuhören.
Was ein Senior Developer ist
Hier wird es interessant. Und hier trennt sich die Spreu vom Weizen — nicht zwischen Junior und Senior, sondern zwischen „Senior als Titel“ und „Senior als Kompetenz.“
Ein Senior Developer kann alles, was ein Mid kann. Das ist die Grundvoraussetzung, und es ist nicht genug. Der Unterschied liegt nicht im Können — der Unterschied liegt im Denken.
Senior denkt in Konsequenzen
Ein Senior sieht nicht nur die Aufgabe. Er sieht nicht nur die Aufgabe und ihre Umgebung. Er sieht die Aufgabe, ihre Umgebung, ihre Konsequenzen und die Konsequenzen der Konsequenzen.
Das ist Senior-Denke. Nicht Code. Konsequenzen! Ketten von Ursache und Wirkung, die über den aktuellen Sprint hinausgehen. Die Frage ist nicht „Können wir das bauen?“ — die Frage ist „Was passiert, wenn wir das bauen? Und was passiert danach? Und was passiert, wenn das, was danach passiert, schiefgeht?“
Senior kommuniziert
Ein Senior kann die technisch korrekte Lösung sein — wenn er sie nicht erklären kann, ist er kein Senior. Senior-Sein bedeutet, die Brücke zwischen Technologie und Geschäft zu sein. Zwischen Entwicklern und Management. Zwischen Jetzt und Übermorgen.
Das bedeutet nicht „PowerPoint für Nicht-Techniker.“ Es bedeutet:
Technische Entscheidungen geschäftlich zu begründen. Nicht „Wir müssen auf PostgreSQL migrieren, weil MySQL keine CTEs unterstützt.“ Sondern „Wir müssen auf PostgreSQL migrieren, weil unsere Reporting-Abfragen aktuell 45 Sekunden dauern. In sechs Monaten, mit dem geplanten Datenwachstum, werden sie 3 Minuten dauern. Das bedeutet: Unsere Monatsabschlüsse werden von 2 Stunden auf 8 Stunden wachsen. Das bedeutet: Die Finanzabteilung bekommt ihre Zahlen nicht mehr rechtzeitig. Das bedeutet: Unser CEO trifft Entscheidungen auf Basis von Daten, die eine Woche alt sind. PostgreSQL mit CTEs und Window Functions reduziert die Abfragezeit auf unter 5 Sekunden. Die Migration kostet zwei Entwicklungsmonate. Die Nicht-Migration kostet die Geschäftsfähigkeit.“
Komplexität zu reduzieren. Nicht durch Vereinfachung — durch Klarheit. Ein Senior kann eine komplexe technische Situation so darstellen, dass ein Nicht-Techniker die Konsequenzen versteht, ohne die Implementierung verstehen zu müssen. Das ist nicht Dummheit des Publikums — das ist Respekt für die Zeit des Publikums.
Nein zu sagen — und das Nein zu begründen. Ein Senior, der nur Ja sagt, ist ein teurer Mid. Ein Senior, der Nein sagt ohne Begründung, ist arrogant. Ein Senior, der Nein sagt und erklärt, warum, und was die Alternative ist — das ist ein Senior.
Senior lehrt
Ein Senior, der sein Wissen nicht teilt, ist ein Mid mit höherem Gehalt. Die Definition von Senior ist nicht, dass er die komplexesten Aufgaben löst. Die Definition von Senior ist, dass er ein Team um sich herum aufbaut, das die komplexen Aufgaben lösen kann, wenn er nicht da ist.
Lehren heißt nicht „Vorträge halten.“ Lehren heißt:
Code-Reviews als Lerngelegenheit. Nicht „Das ist falsch, mach es so.“ Sondern „Das ist ein interessanter Ansatz. Hast du darüber nachgedacht, was passiert, wenn die Liste leer ist? Lass uns darüber reden, wie wir das robust machen können, ohne die Lesbarkeit zu verlieren.“
Architekturentscheidungen transparent machen. Nicht „Wir machen das so.“ Sondern „Wir machen das so, und hier ist, warum. Und hier sind die Alternativen, die wir evaluiert haben, und hier ist, warum sie nicht besser sind. Und wenn jemand eine bessere Alternative hat — immer her damit.“
Raum für Fehler geben. Ein Senior gibt einem Junior eine Aufgabe, die schwer genug ist, um zu lernen, und einfach genug, um nicht zu scheitern. Und wenn der Junior trotzdem scheitert, ist das keine Niederlage — es ist die beste Lerngelegenheit, die es gibt, vorausgesetzt, der Senior fängt den Fehler auf, bevor er in Produktion geht, und dann darüber spricht, was passiert ist und warum.
Senior kennt die Grenzen
Ein Junior denkt, er weiß alles. Ein Mid weiß, dass er nicht alles weiß. Ein Senior weiß, dass niemand alles weiß — und dass das in Ordnung ist.
Senior-Sein bedeutet, komfortabel mit Unsicherheit zu sein. Mit „Ich weiß es nicht, aber ich kann es herausfinden.“ Mit „Diese Entscheidung hat Risiken, und hier ist, wie wir sie mitigieren.“ Mit „Wir haben zwei gute Optionen, und ich kann nicht mit Sicherheit sagen, welche besser ist — aber ich kann eine Empfehlung basierend auf den bekannten Trade-offs geben.“
Das ist keine Schwäche. Das ist die ehrlichste Form von Expertise. Der Junior, der „Ich weiß es nicht“ sagt, ist auf dem Weg zum Senior. Der Senior, der „Ich weiß alles“ sagt, ist auf dem Weg zurück zum Junior — er hat nur noch nicht gemerkt.
Was die Stufen nicht sind
Keine Frage der Jahre
Drei Jahre Erfahrung bedeuten drei Jahre. Sie bedeuten nicht drei Jahre Wachstum. Es gibt Entwickler mit zehn Jahren Erfahrung, die ein Jahr zehn Mal wiederholt haben. Und es gibt Entwickler mit zwei Jahren Erfahrung, die in jedem Jahr mehr gelernt haben als manche in fünf.
Die Frage ist nicht: Wie lange hast du schon programmiert? Die Frage ist: Wie viele verschiedene Probleme hast du gelöst? Wie viele deiner Lösungen haben im Produktivbetrieb funktioniert? Wie viele deiner Annahmen haben sich als falsch herausgestellt — und was hast du daraus gelernt?
Erfahrung ist nicht das, was man gemacht hat. Erfahrung ist das, was man aus dem, was man gemacht hat, gelernt hat.
Keine Frage des Titels
Senior im Titel bedeutet: Das Unternehmen hat entschieden, dich Senior zu nennen. Senior in der Kompetenz bedeutet: Du hast bewiesen, dass du die Denkweise eines Seniors hast. Das sind zwei verschiedene Dinge, und die Diskrepanz zwischen ihnen ist eine der größten Quellen für schlechte Software.
Ich habe „Senior Developers“ gesehen, die jeden Code-Review mit „LGTM“ absegneten, ohne zu lesen. Die Architekturentscheidungen auf Basis von Blogposts trafen, ohne den Kontext zu verstehen. Die neue Technologie einführten, weil sie neu war, nicht weil sie besser war. Die bei Standups sprachen, aber bei Post-Mortems schwiegen.
Und ich habe „Junior Developers“ gesehen, die Fragen stellten, die das Team weiterbrachten. Die in Code-Reviews auf Edge Cases hinwiesen, die alle anderen übersehen hatten. Die dokumentierten, was dokumentiert werden musste, ohne dass jemand sie darum bat.
Der Titel ist eine Konvention. Die Kompetenz ist die Realität. Und wenn die beiden auseinanderfallen, ist das ein Problem — nicht für den Entwickler, sondern für das Unternehmen.
Keine Einbahnstraße
Die Stufen sind keine Hierarchie im Sinne von „Senior ist besser als Mid ist besser als Junior.“ Sie sind Entwicklungsstufen. Jeder Senior war einmal ein Junior. Jeder Senior lernt immer noch — oder sollte es zumindest.
Und die Stufen sind nicht scharf getrennt. Ein Entwickler kann Senior in Backend-Entwicklung sein und Junior in DevOps. Er kann Senior in Systemdesign sein und Mid in Frontend. Er kann Senior in einer Technologie sein und Mid in einer anderen, die er gerade lernt. Das ist normal — und es ist wichtig, das anzuerkennen, sowohl für den Entwickler selbst als auch für das Unternehmen, das ihn beurteilt.
Wie man die Stufen erkennt
Es gibt keine Checkliste, die mit Sicherheit bestimmt, ob jemand Junior, Mid oder Senior ist. Aber es gibt Signale, die ein klares Bild zeichnen.
Junior-Signale: – Fragt „Wie löse ich diese Aufgabe?“ statt „Warum lösen wir diese Aufgabe?“ – Schreibt Code, der funktioniert, aber schwer zu ändern ist – Braucht klare Anforderungen und enge Begleitung – Lernt von Fehlern, wenn sie ihm erklärt werden
Mid-Signale: – Fragt „Gibt es einen besseren Weg, diese Aufgabe zu lösen?“ – Schreibt Code, der funktioniert und wartbar ist – Kann selbstständig arbeiten, aber holt sich Feedback bei Unsicherheit – Macht Fehler, erkennt sie selbst und lernt daraus
Senior-Signale: – Fragt „Ist diese Aufgabe die richtige Aufgabe?“ – Schreibt Code, der anderen als Vorbild dient – Trifft Entscheidungen, die das Team und das Produkt über den aktuellen Sprint hinaus beeinflussen – Macht weniger Fehler, weil er die Fehlermuster kennt — und teilt dieses Wissen
Die wichtigste Unterscheidung ist nicht die technische Fähigkeit. Alle drei Stufen können Code schreiben, der funktioniert. Die Unterscheidung ist die Reichweite der Denkweise: Junior denkt an die Aufgabe. Mid denkt an das System. Senior denkt an die Konsequenzen.
Warum das wichtig ist
Weil Unternehmen ständig die falschen Leute für die falschen Rollen einsetzen. Weil „Senior“ oft bedeutet: „Hat länger durchgehalten.“ Weil „Junior“ oft bedeutet: „Kostet weniger.“ Weil die wichtigste Beförderung in der Softwareentwicklung die vom Mid zum Senior ist — und sie oft auf der falschen Grundlage passiert.
Ein Junior, der als Senior eingesetzt wird, brennt aus — weil die Verantwortung seine Kompetenz übersteigt. Ein Senior, der als Junior eingesetzt wird, brennt aus — weil die Unterforderung seine Motivation zerstört. Und ein Mid, der weder als Junior noch als Senior gesehen wird, brennt aus — weil er weder Mentoring bekommt noch Autonomie.
Die Stufen sind keine Hierarchie. Sie sind ein Rahmen für Entwicklung. Und Entwicklung passiert nicht durch Beförderung. Sie passiert durch Herausforderung, Feedback und die Bereitschaft, die eigene Denkweise zu verändern.
Wer das verstanden hat, ist auf dem Weg zum Senior — unabhängig vom Titel.