Die ersten 90 Tage: Schritt-für-Schritt-Playbook für Softwareentwickler
Du hast dich durch die harten Zeiten gekämpft.
Du hast deinen Lebenslauf auf Hochglanz poliert. Du hast deine Fähigkeiten und Zertifizierungen ausgebaut.
Du hast dein GitHub-Profil auf Vordermann gebracht, Systemdesign-Fragen gebüffelt, bis sie verschwommen, und bei mehr Stellen „Bewerben“ geklickt, als du zählen möchtest.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Du hast dich mutig durch den Interview-Marathon geschlagen—Whiteboard-Aufgaben, Take-Home-Assignments, peinliche Pausen und alles, was dazugehört. Du hast deine Skills weiterentwickelt und bist cool geblieben.
Und dann... kam das Angebotsschreiben. Du hast den Job bekommen! Jetzt beginnt die eigentliche Arbeit.
Denn obwohl das Einstellungsverfahren hart ist, ist ein effektiver Einstieg noch schwieriger. Hier findet der Übergang vom Bewerber zum Mitgestalter statt, und der erste Eindruck wird zum bleibenden. Deine ersten 90 Tage legen das Fundament für alles, was folgt.
In diesem Leitfaden zeige ich dir, wie du als neue:r Softwareentwickler:in direkt durchstarten kannst – mit praktischen Tipps von zwei erfahrenen Tech-Profis, die wissen, worauf es ankommt. Aber zuerst fangen wir mit einem klaren Blick darauf an, was es heutzutage eigentlich bedeutet, Software Engineer zu sein.
Was ist ein Software Engineer?
Oh je, wo soll man da nur anfangen? Im Ernst – zu diesem Thema könnte man ein ganzes Buch schreiben, nicht zuletzt, weil der Begriff oftmals als Sammelbegriff für verschiedene Rollen innerhalb des gesamten Softwareentwicklungszyklus genutzt wird. Deshalb sind hier auch andere Titel wie Entwickler:in oder Programmierer:in oft passend. Wir verwenden ‚Software Engineer‘ als Überbegriff.
Hier ist eine prägnante Definition von Software Engineering, laut Michigan Technological University, die uns den roten Faden gibt: „Software Engineering ist der Zweig der Informatik, der sich mit der Konzeption, Entwicklung, dem Testen und der Wartung von Softwareanwendungen beschäftigt. Software Engineers wenden ingenieurwissenschaftliche Prinzipien und Programmierkenntnisse an, um Softwarelösungen für Endanwender zu erstellen.“
Reduziert auf das Wesentliche heißt das: Software Engineers bauen digitale Dinge, die von Menschen und Maschinen genutzt werden. Anstelle von Hammer und Nägeln benutzen sie Code sowie Werkzeuge wie Git und andere Komponenten.
Wir sollten auch einen der Hauptgründe erwähnen, warum viele Menschen überhaupt als Software Engineer arbeiten möchten: Der Job kann gut bezahlt sein. Die Karriereplattform Glassdoor schätzt das mittlere Gesamtgehalt für Software Engineers auf $147.000 pro Jahr (zuletzt geprüft: 28. April 2025), wobei der tatsächliche Betrag von Faktoren wie Erfahrung, Standort und Branche abhängt.
Schauen wir uns jetzt konkrete Tipps und Ideen an, wie du direkt durchstarten kannst.
Die ersten 30 Tage
In unserem Begleitartikel zu Cybersecurity-Karrieren haben wir darauf hingewiesen, dass sich die ersten 30 Tage letztlich aufs Lernen reduzieren. Das bedeutet: Alles ist neu – vom Code und den Tools bis zu neuen Gesichtern und Orten. Und auch hier gilt das, wenn auch mit ein paar Besonderheiten.
Tipp #1: Nicht alle Tech-Stacks sind gleich
Bei der Navigation in deiner neuen Rolle sollte es ebenso sehr darum gehen, Menschen und Prozesse kennenzulernen, wie den Code oder den Tech-Stack zu verstehen.
„Nach meiner Erfahrung in großen Unternehmen ist es wichtiger, die Menschen [und] Prozesse zu verstehen als die Architektur des Codes“, sagt Justin Garrison, Head of Product bei Sidero Labs. Vor seiner aktuellen Rolle war Justin Senior Developer Advocate bei AWS und in diversen technischen Positionen bei Disney tätig, darunter auch als Senior Software Engineer.
Tipp #2: Verstehe, wie das Unternehmen Umsatz generiert
Um deinen Wert zu maximieren, musst du verstehen, wie die Organisation ihren Wert erschafft.
„Neben dem Kennenlernen des technischen Stacks und der Anforderungen sollten Engineers herausfinden, wie das Geschäft Wert schafft und Geld verdient“, berichtet uns Chris Carter, Principal Product Manager bei NetApp Instaclustr. Bevor er seine aktuelle Rolle übernahm, begann Chris bei dem Unternehmen als Senior Development Engineer und war später Teamlead. Er ergänzt:
„Direkte Abonnements? Vertriebsteam und individuelle Deals? Aufmerksamkeit und Werbung? Finde heraus, wie das Unternehmen sich misst und wie es von Code zu KPI gelangt.“
Bau dir dieses Verständnis früh auf. Software Engineers, die die Verbindung zwischen ihrem Code und der finanziellen Performance ihres Unternehmens verstehen, werden immer gefragt bleiben.
„Wenn du verstehst, wie das Unternehmen seinen Erfolg misst, kannst du dich so positionieren, dass du Teil dieses Erfolgs wirst und zum Geschäftsergebnis beiträgst,“ sagt Chris.
Tipp #3: Klone das Repository, aber gehe beim Commit nicht überstürzt vor
Klar, du bist gespannt auf deinen ersten Pull Request. Doch behandle den Code wie einen lebenden Organismus: Beobachte seine Muster, verstehe seine Struktur und stelle Fragen, bevor du Änderungen vornimmst. Nutze die Code-Navigationsfunktionen deiner IDE, Grep-Befehle oder die Projektsuche, um nachzuvollziehen, wie Daten und Logik durch das System fließen.
Und falls du hängen bleibst? Versuche, das Verhalten lokal zu reproduzieren und geh dann Schritt für Schritt vor. Debugger sind unterschätzt, und Erklären am „Gummienten-Prinzip“ funktioniert immer noch.
Profi-Tipp: Schau dir kürzlich gemergte PRs an, um den Codestil, die Feedbackkultur und zu verstehen, wie „fertig“ in deinem Team wirklich aussieht.
Die ersten 60 Tage
Eine der besten Möglichkeiten, schnell durchzustarten, ist neugierig zu sein – nicht nur darauf, was der Code macht, sondern auch warum er es genau so macht.
Tipp #4: Frage dich: „Warum wurde das so gebaut?“
Legacy-Code sieht manchmal nach Spaghetti aus, doch oft steckt Substanz in der Soße. Einschränkungen durch einen mittlerweile eingestellten Service, ein Performance-Kompromiss, geschäftliche Anforderungen einer ausgelaufenen Produktfunktion – diese Entscheidungen haben eine Geschichte. Wenn du diese Geschichte kennst, vermeidest du Vorschläge, die schon ausprobiert (und verworfen) wurden, und stärkst deine Glaubwürdigkeit.
Starte mit interner Dokumentation (auch wenn sie veraltet ist). Bitte dann eine Kollegin oder einen Kollegen, dir etwas Unverständliches zu erklären, und betrachte sie als Mitautoren der System-Geschichte.
„Welche Entscheidungen sind in diesem Code verschlüsselt?“ ist die bessere Frage als „Warum ist dieser Code so schlecht?“
Tipp #5: Finde die „ungeschriebenen Regeln“ deines Teams heraus
Jede Entwicklungsabteilung hat solche Regeln. Vielleicht bevorzugt das Team RFCs in Notion statt Jira-Tickets, alle deployen donnerstags, oder Unittests sind optional – aber End-to-End-Tests sind heilig.
Solche Normen stehen meist nicht im Handbuch, beeinflussen deinen Erfolg aber genauso wie deine technischen Fähigkeiten. Beobachte Slack-Muster, analysiere Git-Commit-Messages und frage die Kolleginnen und Kollegen, was sie gerne bei ihrem Einstieg gewusst hätten.
Tipp #6: Triff dich weiterhin mit Menschen – und lerne von ihnen
Justin von Sidero Labs stellt fest, dass das Kennenlernen von Menschen hilft, als Engineer Systeme über den reinen Code hinaus ganzheitlich zu verstehen: „Am Ende solcher Meetings war es viel leichter zu verstehen, warum Systeme so aussehen, wie sie aussehen.“
Das bringt viele Vorteile mit sich und sorgt beispielsweise dafür, dass du entspannter reagierst, wenn der Code anfangs keinen Sinn zu ergeben scheint. Wenn ein Mensch ihn geschrieben hat, hatte dieser wahrscheinlich einen Grund dafür – sei es eine organisatorische Vorgabe, Zeitdruck oder Ähnliches.
Diese Art des ganzheitlichen Verständnisses hilft nicht nur in Bezug auf Teamkultur und Kommunikation, sondern auch bei Empathie und Diplomatie, wenn es darum geht, Verbesserungen vorzuschlagen oder einzuführen.
Die ersten 90 Tage
Nun bist du angekommen: „Nach 90 Tagen solltest du auf festem Boden stehen und in der Lage sein, größere Aufgaben selbstständig zu übernehmen,“ sagt Chris von NetApp Instaclustr.
In dieser letzten Phase geht es wirklich darum, zu planen und mit der Umsetzung zu beginnen. Wo kannst
du wirklich Wirkung zeigen?
Tipp #7: Optimiere gezielt – mit Sinn und Wirkung
Nach 90 Tagen bist du nicht mehr nur „der neue Entwickler“ – du entwickelst dich zum aktiven Beitragenden. Jetzt ist es an der Zeit, nach Verbesserungsmöglichkeiten zu suchen. Aber: Nicht jede Optimierung lohnt sich und nicht jeder Fehler muss behoben werden.
„Es geht nicht darum, eine lange Liste aller defekten Dinge zu erstellen,“ sagt Chris. „Es geht darum, das Geschäft, die Kunden und den Kontext zu verstehen – und mit diesem Wissen sinnvolle Verbesserungen zu identifizieren.“
So gehen Chris und sein Team dabei vor:
- Denke in Ursachen: Starte nicht direkt mit der Lösung – beginne mit klaren Tickets, die das Problem beschreiben.
- Priorisiere klug: Finde heraus, wie dein Team Wirkung, Aufwand und Dringlichkeit abwägt. Ein kleiner UI-Bug auf einem auslaufenden Screen? Vermutlich keine Priorität.
- Kundenorientiert denken: Frage dich immer, „Ist das für echte Nutzer relevant?“ Wenn nicht, hake es ab und mach weiter.
Hast du Systeme und Kultur erst einmal verstanden, suche aktiv Aufgaben mit großem Hebel – Dinge, die Reibung reduzieren, die Lieferung verbessern oder das Kundenerlebnis stärken.
„Wenn du kontinuierlich Arbeit ablieferst, die das Geschäft voranbringt, wirst du schnell als jemand wahrgenommen, der es verstanden hat – und dem man auch größere Aufgaben zutrauen kann,“ sagt Chris.
Tipp #8: Versende etwas. Egal was. Aber übernimm die Verantwortung.
Bis Tag 90 musst du keinen Kerndienst neu geschrieben oder alleine ein neues Feature veröffentlicht haben. Aber du solltest in der Lage sein, auf eine Sache zu zeigen, und sei sie noch so klein, die du von Anfang bis Ende umgesetzt und verantwortet hast.
Das könnte sein:
- Ein Bugfix, der die Nutzerreibung reduziert hat
- Eine CI/CD-Pipeline-Anpassung, die Builds beschleunigt hat
- Eine Überarbeitung des README, die dem nächsten neuen Mitarbeitenden hilft
- Eine Backend-Optimierung, die eine häufige Abfrage um 50 ms beschleunigt hat
Es muss nicht spektakulär sein – es muss nützlich sein. Wirkung entsteht nicht durch Glanz, sondern durch Funktion.
Mantra für Entwickler: „Habe ich das Leben des Teams diese Woche um 1 % verbessert?“
Tipp #9: Richte einen persönlichen Lern-Backlog ein
Du wirst in 90 Tagen nicht den gesamten Code, die Infrastruktur und die Geschäftslogik beherrschen. Das ist in Ordnung. Wichtig ist, was du danach tust.
Lege einen persönlichen „Backlog“ mit Fähigkeiten und Wissenslücken an. Notiere dir:
- Bereiche des Systems, die du noch nicht verstehst
- Tools oder Frameworks, in die du tiefer eintauchen möchtest (z. B. Kubernetes, gRPC, Terraform)
- Technische Schulden oder Eigenheiten, die du noch einmal anschauen möchtest
Priorisiere dann pro Sprint eine Sache und hake sie ab. Du lernst nicht nur das System kennen – du gestaltest deinen eigenen Entwicklungsfahrplan.
Abonniere den Newsletter des CTO Club, um weitere Playbooks für deine ersten 90 Tage in jeder Tech-Rolle zu erhalten!
