Frag eine Ingenieurin, was sie diese Woche gemacht hat, und kaum etwas in der Antwort wird sein, neue Logik in eine leere Datei zu tippen.
Wo die Zeit tatsächlich hingeht
Das öffentliche Bild des Jobs ist Komposition. Die Realität ist näher an Archäologie, Verhandlung und Reparatur.
Bestehenden Code lesen, um zu verstehen, was er tut. Einen gemeldeten Fehler reproduzieren. Die Änderung von jemand anderem reviewen. In ein System integrieren, dessen Dokumentation veraltet ist. Auf einen Build warten. Einen Ansatz diskutieren. Deployen. Untersuchen, warum sich das Deployment anders verhalten hat als die Testumgebung. Etwas reparieren, das zwei Jahre funktioniert hat und dann aufgehört hat.
Tatsächlich neuen Code zu schreiben ist ein echter Teil der Arbeit, aber nicht der größte, und selten der Teil, der über Erfolg oder Misserfolg des Projekts entscheidet.
Der Engpass in den meisten Software-Teams ist Verständnis und Koordination, nicht Tippgeschwindigkeit.
Das hat eine direkte Konsequenz fürs Training. Ein Weiterbildungsprogramm, das sich vollständig auf Sprachen und Frameworks konzentriert, trainiert die kleinere Hälfte des Jobs. Die Fähigkeiten, die über den Ausgang entscheiden – unbekannte Systeme lesen, gut reviewen, für Veränderung designen, eine technische Entscheidung kommunizieren – sind lehrbar und werden meist dem Zufall überlassen.
Was die Richtung abdeckt
Der Umfang: Architektur, Code, Tests, Programmierschnittstellen, Versionskontrolle, Deployment und Teamarbeit.
Vier Bereiche.
Konstruktion. Sprachen, Design, Schnittstellen und das Handwerk, Code zu schreiben, den andere ändern können.
Verifikation. Tests auf jeder Ebene, Review und die Disziplin zu wissen, was tatsächlich geprüft wurde.
Delivery. Versionskontrolle, Continuous Integration, Deployment und Release-Praxis.
Zusammenarbeit. Im Team an einem gemeinsamen System zu arbeiten – wo der größte Teil der Schwierigkeit in kommerzieller Software tatsächlich liegt.
Der größte Stellenzuwachs in der ganzen Tabelle
Lohnt sich, präzise zu benennen, denn die öffentliche Debatte über diesen Beruf ist konfus geworden.
Das US Bureau of Labor Statistics prognostiziert für Softwareentwickler ein Beschäftigungswachstum von 15,8 Prozent zwischen 2024 und 2034, ein Plus von 267.700 Stellen. In derselben Prognosereihe ist das der größte absolute Zuwachs unter den erfassten Tech-Berufen, in absoluten Zahlen größer als Data Scientists und IT-Sicherheitsanalysten zusammen, obwohl beide prozentual stärker wachsen. Die Gesamtbeschäftigung über alle Berufe soll im selben Zeitraum um 3,1 Prozent wachsen.
Zwei Einschränkungen gehören sofort neben diese Zahl, und sie wegzulassen wäre unehrlich.
Es ist eine Prognose. Prognosen sind Modelle auf Basis von Annahmen über Technologieadoption und Branchenwachstum, und sie werden überarbeitet. Diese hier enthält eine Annahme über KI-getriebene Produktivitätssteigerung, weshalb dieselbe Tabelle mehrere administrative Berufe rückläufig zeigt.
Das Einstiegsniveau tut sich schwer. Absolventen und Quereinsteiger sind auf einen engeren Markt gestoßen, als die Schlagzeile mit der Wachstumszahl nahelegt, und ein aggregiertes Jahrzehnt-Wachstum sagt nichts darüber aus, wie leicht ein erster Job in einem bestimmten Jahr zu bekommen ist.
Die Auflösung: Ein großer Teil der prognostizierten offenen Stellen entsteht durch Ersatzbedarf statt durch Expansion, und die Nachfrage neigt zu Leuten, die mit bestehenden Systemen arbeiten können. Das ist eine Aussage darüber, welches Training sich auszahlt, kein Argument, dass das Wachstum fiktiv wäre.
Review ist die Fähigkeit, die ein Team skaliert
Die lehrbare Fähigkeit mit dem höchsten Hebel in der Softwareentwicklung, und eine, die fast keine Organisation bewusst lehrt.
Code-Review ist da, wo Fehler abgefangen werden, bevor sie etwas kosten, wo sich Wissen im Team verbreitet, wo Standards real statt nur dokumentiert werden, und wo Junior-Ingenieure am schnellsten lernen. Es ist auch da, wo viel Zeit verschwendet wird und wo überraschend viel Arbeitsplatzkonflikt entsteht.
Vier Dinge, die nützliches Review von Ritual unterscheiden.
Wissen, worauf man achtet. Korrektheit, Fehlerbehandlung, Sicherheit, Skalierungsverhalten und ob das in einem Jahr noch verständlich ist. Formatierung sollte ein Tool übernehmen, und genau darauf richten unerfahrene Reviewer ihre Aufmerksamkeit.
Das Design reviewen, nicht den Diff. Der wertvollste Kommentar lautet oft, dass die Änderung in dieser Form gar nicht existieren sollte, und dieser Kommentar ist viel günstiger, bevor die Arbeit erledigt ist.
Trennen, was sich ändern muss, von dem, was man selbst anders gemacht hätte. Vorliebe mit Anforderung zu verwechseln ist die mit Abstand größte Reibungsquelle im Review, und sie bringt Leuten bei, aufzuhören zu fragen.
Es sicher machen. Eine Review-Kultur, in der Leute Kritik fürchten, erzeugt kleinere, spätere, weniger ehrliche Änderungen und versteckt Probleme, bis sie teuer sind.
Nichts davon ist schwer zu lehren. Es wird einfach angenommen, man lerne es durch Ausgesetztsein, und Leute lernen das, was ihr erstes Team zufällig getan hat.
Wo das in der Domäne steht
Softwareentwicklung ist die zweite von acht Richtungen in Astra Trainers Domäne KI, Daten und Computing, und sie ist in fast jeder Partnerorganisation die größte nach Kopfzahl. Sie stützt sich auf Computer Science für das zugrunde liegende Modell und verbindet sich vorwärts mit Cloud Computing und DevOps, wo die Delivery-Hälfte des Jobs heute lebt.
Sie verbindet sich außerdem mit Cybersecurity, da ein großer Teil der Schwachstellen gewöhnliche Software-Fehler sind, und mit künstlicher Intelligenz und maschinellem Lernen, wo die Systeme rund um ein Modell klassische Softwareentwicklung sind. Hier findest du die acht Richtungen.
Wartung ist der Job, nicht die Nachwehen
Software ist beim Release nicht fertig. Der größte Teil des Geldes, das über die Lebensdauer eines Systems ausgegeben wird, fällt nach dem ersten Release an, und die meisten Ingenieure verbringen den Großteil ihrer Karriere mit bereits bestehendem Code.
Trotzdem nutzt fast die gesamte technische Ausbildung Greenfield-Übungen. Leute lernen, isoliert etwas Neues zu bauen, mit sauberen Anforderungen und ohne Historie, und werden dann in ein System eingestellt mit fünfzehn Jahren angesammelter Entscheidungen, halb fertigen Migrationen und Kommentaren, die ein Verhalten beschreiben, das sich längst geändert hat.
Die Fähigkeiten, die diese Lücke verlangt, sind spezifisch und lehrbar.
Unbekannten Code lesen. Den Einstiegspunkt finden, einen Pfad verfolgen, ein funktionierendes mentales Modell bauen, ohne alles zu lesen.
Code sicher ändern. Tests zu ungetestetem Code hinzufügen, bevor man ihn ändert, kleine, umkehrbare Änderungen machen und Typen und Verträge nutzen, um die Wirkung einer Änderung zu begrenzen.
Verstehen, warum etwas ist, wie es ist. Vieles, was in Legacy-Code irrational aussieht, war eine korrekte Reaktion auf eine Einschränkung, die nicht mehr existiert, oder auf einen Bug, an den sich niemand mehr erinnert. Es zu löschen, ohne zu wissen, was von beidem, führt zu Ausfällen.
Technische Schulden ehrlich managen. Entscheidungen, die vernünftige Kompromisse waren, von angesammelter Vernachlässigung unterscheiden und die Kosten von jedem für die Leute sichtbar machen, die Prioritäten entscheiden.
Inkrementell migrieren. Fast jede große Neuschreibung, die als einzelner Ersatz versucht wurde, ist eine Warngeschichte. Inkrementelle Migration ist eine Fähigkeit mit bekannten Mustern, und sie wird selten gelehrt.
Die Rollen im Überblick
Softwareentwicklerinnen, über Front End, Back End und Full Stack hinweg.
Platform Engineers, die das interne Tooling bauen, auf das andere Teams angewiesen sind.
Mobile Engineers.
Quality- und Test-Engineers, einschließlich Automatisierung.
Site Reliability Engineers, wo Softwareentwicklung auf Betrieb trifft.
Technische Architektinnen.
Engineering-Managerinnen und Tech Leads, wo die Beschränkung meist Urteilsvermögen ist, nicht Codierfähigkeit.
Developer-Experience-Engineers, ein wachsendes Spezialgebiet, das genau auf den Verständnis- und Koordinationsengpass zielt.
Integrationsingenieure, die Systeme verbinden, die nie dafür gebaut wurden, aufeinanderzutreffen.
Wer sich dafür weiterbilden kann
Qualitätssicherungs- und Test-Ingenieurinnen. Die stärkste interne Konversion. Sie kennen das Produkt bereits, wissen, wie es scheitert, und kennen die Codebasis von außen.
Support- und Betriebsingenieure. In die Entwicklung, mit Produktionswissen, das Entwicklungsteams fehlt und oft brauchen.
Datenanalystinnen. Schreiben bereits Code, mit Bedarf an Engineering-Praxis: Versionskontrolle, Tests, Review und Design für Veränderung.
Business-Analysten und Product-Mitarbeitende mit technischer Neigung, in entwicklungsnahe Rollen, wo Domänenverständnis die knappe Hälfte ist.
Ingenieure aus anderen Disziplinen. Maschinenbau-, Elektro- und Bauingenieurinnen konvertieren gut und bringen systematische Methodik mit.
Wissenschaftler und Forscherinnen, die für ihre eigene Arbeit bereits Code schreiben, mit Bedarf an kollaborativer Praxis statt Programmieren.
Erfahrene Entwickler in alternden Technologien. Oft übersehen, mit tiefem Systemwissen und Bedarf an einer aktuellen Toolchain statt einem Karrierewechsel.
Zu generiertem Code und Verantwortung. Von Generierungs-Tools produzierter Code liegt in der Verantwortung der Organisation, die ihn ausliefert, und kann Fehler, Sicherheitslücken, lizenzrechtliche Implikationen oder Verhalten enthalten, das niemand im Team erklären kann. Review-, Test- und Herkunftspflichten übertragen sich nicht auf das Tool. Branchen mit regulierter Software, darunter Medizin, Automobil, Luftfahrt und Finanzsysteme, haben spezifische Anforderungen an Entwicklungsprozess und Rückverfolgbarkeit, die unabhängig davon gelten, wie der Code entstanden ist.
Was du mitnehmen solltest
Neuen Code zu produzieren ist die Minderheit des Jobs, und Training, das nur Sprachen und Frameworks abdeckt, adressiert die kleinere Hälfte.
Softwareentwickler sollen laut Prognose bis 2034 um 267.700 Stellen zunehmen, der größte absolute Zuwachs unter den vom BLS erfassten Tech-Berufen, und das ist eine Prognose neben einem echt schwierigen Einstiegsmarkt.
Code-Review ist die lehrbare Fähigkeit mit dem höchsten Hebel in einem Team und wird fast überall dem Zufall überlassen.
Wartungs- und Legacy-Arbeit ist, wo Karrieren tatsächlich verbracht werden, und Ausbildung trainiert überwältigend für Greenfield.
Und die besten internen Kandidaten stecken meist in Test, Support und Betrieb, mit Wissen, für das neue Mitarbeitende ein Jahr brauchen.
Womit verbringen Softwareentwickler tatsächlich ihre Zeit?
Mit Lesen bestehenden Codes, Reproduzieren von Fehlern, Reviewen von Änderungen, Integrieren mit Systemen mit veralteter Dokumentation, Deployen und Untersuchen von Unterschieden zwischen Umgebungen. Neuen Code zu schreiben ist real, aber nicht der größte Anteil.
Wächst Softwareentwicklung als Beruf noch?
Das BLS prognostiziert 15,8 Prozent Wachstum von 2024 bis 2034, ein Plus von 267.700 Stellen, der größte absolute Zuwachs unter den erfassten Tech-Berufen. Das ist eine Prognose statt einer Beobachtung, und sie besteht neben einem schwierigen Einstiegsarbeitsmarkt.
Warum ist Code-Review so wichtig?
Weil es Fehler abfängt, bevor sie etwas kosten, Wissen im Team verbreitet, Standards real macht und Junior-Ingenieure schneller schult als alles andere. Es ist auch, wo die meiste technische Reibung entsteht, wenn es schlecht gemacht wird.
Warum ist Legacy-Code-Arbeit untertrainiert?
Weil technische Ausbildung Greenfield-Übungen mit sauberen Anforderungen nutzt, während die meisten Ingenieure den Großteil ihrer Karriere damit verbringen, Systeme mit jahrelanger angesammelter Historie, halb fertigen Migrationen und undokumentierten Gründen zu ändern.
Wer konvertiert gut in Softwareentwicklung?
Test- und Qualitätsingenieure zuerst, dann Support- und Betriebspersonal, Datenanalysten, die bereits Code schreiben, Ingenieure aus anderen Disziplinen, und erfahrene Entwickler in alternden Technologien, die eine aktuelle Toolchain statt einen Karrierewechsel brauchen.