Die Sprache ist schnell gelernt, das Drumherum nicht

Was den Arbeitstag tatsächlich füllt

Neuer Code ist der kleinste Posten. Den größten Teil machen Lesen und Ändern von Bestehendem aus, dazu Fehlersuche, Code-Review für andere, Abstimmung mit dem Fachbereich darüber, was eine Anforderung eigentlich bedeutet, und die Pflege der Werkzeugkette. Wer sich Entwicklung als stundenlanges konzentriertes Schreiben vorstellt, erlebt in den ersten Wochen eine Enttäuschung, die nichts mit dem eigenen Können zu tun hat.

Die zweite falsche Erwartung betrifft die Vielfalt der Aufgaben. In vielen Java-Häusern arbeitet man jahrelang an derselben großen Anwendung, und der Reiz liegt nicht im Neubau, sondern darin, ein System, das seit fünfzehn Jahren Geld verdient, verständlich und änderbar zu halten. Das ist eine eigene Fähigkeit, sie wird gut bezahlt, und sie ist etwas anderes als das Aufsetzen neuer Dienste.

Ein Betriebsthema, das viele überrascht, ist die Versionsfrage. Java hat Langzeitversionen, und viele Bestandssysteme laufen auf einer älteren davon. Der Sprung nach oben ist meist kein Sprachthema, sondern ein Abhängigkeitsthema: Bibliotheken müssen mitziehen, und beim Wechsel der Unternehmensplattform hat sich vor einigen Jahren zusätzlich der Namensraum der Schnittstellen von javax auf jakarta geändert, was jede betroffene Bibliothek betrifft. Wer bei einem solchen Umstieg schon einmal mitgearbeitet hat, hat ein Gesprächsthema, das ihn von anderen Bewerbern unterscheidet.

Dazu kommt eine Lizenzfrage, die keine Sprachfrage ist. Es gibt viele Bauversionen desselben offenen Quellstands, etwa von Eclipse Adoptium, Amazon, Azul, Red Hat oder Microsoft, und sie sind für den Betrieb frei nutzbar. Nur der Build des ursprünglichen Herstellers steht unter eigenen Bedingungen mit einem Abonnementmodell. In vielen Häusern ist auf Entwicklungsrechnern über Jahre der falsche Build gelandet, und aufgefallen ist es erst bei einer Prüfung.

Der Weg hinein, und welche Nachweise zählen

Formal führen zwei Wege in die Rolle: die Ausbildung zum Fachinformatiker für Anwendungsentwicklung und ein Studium der Informatik oder eines verwandten Fachs. Der dritte Weg, der Quereinstieg, ist in der Java-Welt verbreiteter, als viele denken, weil der Bedarf im Bestand groß ist und Häuser mit langlebigen Systemen eher jemanden einarbeiten als eine Stelle unbesetzt lassen.

Was in der Bewerbung wirklich zählt, ist ein Projekt, das jemand anders bauen und starten kann. Konkret: ein Verzeichnis mit Quellcode, eine Build-Datei, eine kurze Anleitung, Tests, die durchlaufen, und eine Anwendung, die nach dem Start tatsächlich etwas tut. Das schlägt jede Kursliste, weil es genau die Fragen beantwortet, die im Fachgespräch gestellt werden: Warum hast du das so geschnitten, was passiert, wenn die Datenbank nicht erreichbar ist, wie würdest du diese Funktion testen.

Zertifizierungen zur Sprache spielen im deutschsprachigen Raum eine kleinere Rolle als in anderen Märkten. Sie schaden nicht und können in der Vorauswahl bei Dienstleistern helfen, ersetzen aber weder Code noch die Fähigkeit, über eigene Entscheidungen zu sprechen. Deutlich mehr Wirkung hat es, wenn du erklären kannst, warum du in deinem Projekt an einer Stelle bewusst gegen die naheliegende Lösung entschieden hast.

Woran zwei Leute mit gleicher Berufsdauer auseinandergehen

Der erste Unterschied ist der Schnitt. Es gibt Entwickler, deren Code funktioniert, und solche, deren Code sich in zwei Jahren noch ändern lässt, ohne dass jemand Angst davor hat. Der Unterschied liegt in Kleinigkeiten, die sich benennen lassen: klare Zuständigkeit je Klasse, Abhängigkeiten von außen hereingereicht statt im Inneren erzeugt, keine Geschäftslogik im Datenzugriff, und Tests, die sich lesen lassen wie eine Beschreibung des erwarteten Verhaltens.

Der zweite Unterschied ist die Fehlersuche in Produktion. Wer bei einem Problem, das sich lokal nicht nachstellen lässt, nach Speicherabbild, Threadauszug und Protokollen der Speicherbereinigung greift und daraus eine Hypothese baut, ist in jedem Team die Person, die man anruft. Diese Fähigkeit entsteht nicht aus Kursen, sondern daraus, dass man sie einmal unter Druck gebraucht hat und danach systematisch geübt hat.

Der dritte Unterschied ist Fachwissen aus der Domäne. Java sitzt in Branchen mit komplizierten Regeln: Versicherungsmathematik, Zahlungsverkehr, Logistik, Fertigungssteuerung. Wer die Regeln versteht, mit denen sein Haus Geld verdient, schreibt nicht nur den Code, sondern erkennt, wenn eine Anforderung fachlich nicht stimmen kann. Das ist der Punkt, an dem aus einem Entwickler eine Person wird, die in Entscheidungen einbezogen wird.

Wohin die Rolle führt

Die erste Richtung ist die Architektur. Wer über Jahre gesehen hat, welche Entwürfe alterungsbeständig waren und welche nicht, wird zu der Person, die den Schnitt neuer Systeme verantwortet und Entscheidungen begründet aufschreibt. Diese Rolle bleibt technisch, verlagert sich aber von der Umsetzung auf Abwägung und Vermittlung.

Die zweite Richtung ist der Betrieb der eigenen Software. Container, Auslieferungsketten, Messwerte und Verfügbarkeit sind für Java-Anwendungen ein eigenes Fachgebiet geworden, und wer aus der Entwicklung kommt, bringt dafür den Vorteil mit, den Code zu kennen, den er betreibt. Die Testautomatisierung ist ein verwandter Weg, der ähnlich viel Bestandserfahrung verlangt.

Die dritte Richtung führt weg vom Code: Fachliche Analyse, Anforderungsarbeit, Teamleitung. Und dann gibt es noch die Bewegung innerhalb der Plattform. Wer auf der Java-Laufzeitumgebung bleibt, aber die Sprache wechselt, findet dort Kotlin und andere Sprachen, die dieselben Bibliotheken nutzen. Die Entwicklung für Android baut ebenfalls auf dieser Welt auf, ist aber ein eigener Beruf mit eigenen Werkzeugen und eigenem Veröffentlichungsweg.