20 Jahre Code — Was ich gelernt habe

Ein Rueckblick

Vor zwanzig Jahren habe ich meinen ersten professionellen Code geschrieben. PL/I auf einem IBM-Mainframe, in einer Bank in Oesterreich. Der Editor war gruen auf schwarz, die Deployment-Zyklen dauerten Tage, und “agil” war ein Wort, das niemand kannte. Heute baue ich KI-gestuetzte Entwicklungsumgebungen und arbeite taeglich mit Sprachmodellen. Zwischen diesen beiden Punkten liegen zwei Jahrzehnte voller Fehler, Erkenntnisse und einiger weniger wirklich guter Entscheidungen.

Hier sind die fuenf wichtigsten Lektionen, die ich in dieser Zeit gelernt habe.

Lektion 1: Die Sprache ist egal, das Denken zaehlt

Ich habe in meiner Karriere mit PL/I, COBOL, C#, Java, JavaScript, TypeScript, Python und diversen anderen Sprachen gearbeitet. Und die wichtigste Erkenntnis ist: Die Programmiersprache ist ein Werkzeug, nicht eine Identitaet.

In meinen fruehen Jahren habe ich mich als ”.NET-Entwickler” definiert. Ich war in C#-Foren aktiv, habe C#-Blogs gelesen, habe auf Konferenzen ueber C# gesprochen. Wenn jemand Python oder Java erwaehnte, habe ich die Nase geruempft.

Das war dumm.

Die besten Entwickler, die ich kenne, denken nicht in einer Sprache. Sie denken in Konzepten: Datenstrukturen, Algorithmen, Architekturmuster, Systemdesign. Die Sprache ist die Syntax, mit der sie diese Konzepte ausdruecken. Und eine neue Syntax zu lernen, dauert Wochen, nicht Jahre.

Als ich von C# zu TypeScript wechselte, war das Schwierigste nicht die Sprache — es war das OEkosystem. npm statt NuGet, Express statt ASP.NET, ein anderes Tooling. Aber die Konzepte? Die waren die gleichen. Dependency Injection ist Dependency Injection, egal ob in C# oder TypeScript.

Mein Rat: Lernt Konzepte, nicht Sprachen. Und wenn ihr eine neue Sprache lernen muesst, seht es als Chance, euren Horizont zu erweitern, nicht als Bedrohung.

Lektion 2: Ship early, iterate fast

In meinem ersten Job in der Bank dauerte ein Release-Zyklus sechs Monate. Wir haben monatelang geplant, monatelang implementiert, wochenlang getestet und dann mit angehaltenem Atem deployt. Meistens ging etwas schief.

Spaeter, als ich in der Eventbranche arbeitete, musste ich lernen, schnell zu liefern. Events haben feste Termine — wenn das System am Festivaltag nicht laeuft, gibt es keine Verlaengerung. Das hat mich gelehrt, das Minimum zu identifizieren, das funktionieren muss, es zu bauen und dann zu iterieren.

Diese Lektion hat mein gesamtes Denken ueber Software veraendert. Heute bin ich ueberzeugt: Die groesste Gefahr in der Softwareentwicklung ist nicht, etwas Unfertiges zu liefern. Es ist, zu spaet zu liefern.

Jede Woche, die ich an einem Feature arbeite, ohne es Nutzern zu zeigen, ist eine Woche, in der ich moeglicherweise in die falsche Richtung laufe. Feedback ist der Kompass der Produktentwicklung, und ohne Feedback navigiere ich blind.

Das heisst nicht, dass Qualitaet unwichtig ist. Es heisst, dass die Definition von “fertig” sich veraendern muss. Version 1 muss nicht perfekt sein. Sie muss funktionieren, und sie muss schnell bei den Nutzern sein. Perfektion kommt durch Iteration, nicht durch Planung.

Lektion 3: Komplexitaet ist der Feind

Wenn ich auf die Projekte zurueckblicke, die gescheitert sind — und es gibt einige — hatten sie alle etwas gemeinsam: Sie waren zu komplex. Nicht komplex in dem Sinne, dass das Problem komplex war, sondern komplex in dem Sinne, dass die Loesung unnoetig komplex war.

Ich erinnere mich an ein Projekt in der Logistikbranche, bei dem wir ein einfaches Tracking-System bauen sollten. Wir haben eine Microservices-Architektur mit Event Sourcing, CQRS, und einem eigenen Message Broker implementiert. Fuer ein System, das im Kern eine Datenbank und ein paar REST-Endpoints war. Das Projekt hat doppelt so lange gedauert wie geplant und war kaum wartbar.

Die Lektion: Jede Architekturentscheidung hat Kosten. Microservices loesen echte Probleme, aber sie bringen auch echte Komplexitaet mit sich. Event Sourcing ist elegant, aber es macht Debugging zur Hoelle. CQRS ist maechtig, aber es verdoppelt die Menge an Code.

Heute frage ich bei jeder Architekturentscheidung: “Was ist die einfachste Loesung, die funktioniert?” Nicht die eleganteste, nicht die skalierbarste, nicht die trendigste — die einfachste. Und dann baue ich das. Wenn ich spaeter skalieren muss, kann ich das immer noch tun. Aber ich baue nicht heute fuer Probleme, die ich morgen vielleicht habe.

Lektion 4: DevOps ist kein Job, sondern eine Denkweise

Frueh in meiner Karriere gab es “die Entwickler” und “die Admins.” Wir haben Code geschrieben und ihn ueber den Zaun geworfen. Die Admins haben ihn deployt und sind um drei Uhr morgens aufgestanden, wenn er abgestuerzt ist. Das war das Modell, und niemand hat es in Frage gestellt.

Dann kam DevOps, und ich habe zunaechst gedacht, es sei einfach ein neuer Name fuer Systemadministration. Es hat Jahre gedauert, bis ich verstanden habe, dass DevOps eine fundamentale Veraenderung in der Denkweise ist.

DevOps bedeutet, dass ich als Entwickler Verantwortung fuer meinen Code uebernehme — nicht nur dafuer, dass er kompiliert, sondern dass er laeuft, skaliert, ueberwacht und wiederhergestellt werden kann. Es bedeutet, dass Deployment kein Event ist, sondern ein Prozess. Es bedeutet, dass Infrastruktur Code ist.

Diese Denkweise hat mich zu einem besseren Entwickler gemacht. Nicht weil ich jetzt Terraform-Dateien schreiben kann, sondern weil ich beim Schreiben von Code schon an Deployment, Monitoring und Fehlerbehandlung denke. Ich schreibe heute besseren Code, weil ich weiss, wie er in Produktion laeuft.

Lektion 5: KI ersetzt keine Entwickler, sie verstaerkt gute

Diese Lektion ist die neueste, und ich lerne sie jeden Tag ein bisschen mehr. Seit ich mit KI-Coding-Agenten arbeite, habe ich festgestellt: Die Qualitaet des Outputs ist direkt proportional zur Qualitaet des Inputs. Ein guter Entwickler bekommt aus einem KI-Agenten brillante Ergebnisse. Ein schlechter Entwickler bekommt schlechte Ergebnisse und merkt es nicht einmal.

Warum? Weil ein guter Entwickler weiss, welche Fragen er stellen muss. Er kann die Architektur vorgeben, den Kontext liefern, die Ergebnisse bewerten und den Agenten in die richtige Richtung lenken. Er nutzt die KI als Multiplikator seiner eigenen Faehigkeiten.

Ein Entwickler, der die Grundlagen nicht versteht, kann nicht beurteilen, ob der KI-Output gut oder schlecht ist. Er akzeptiert Code, der auf den ersten Blick funktioniert, aber Sicherheitsluecken hat, nicht skaliert oder unwartbar ist.

Mein Fazit nach zwanzig Jahren: Investiert in eure Grundlagen. Versteht Datenstrukturen, Algorithmen, Systemdesign, Sicherheit. Lernt, klar zu denken und klar zu kommunizieren. Diese Faehigkeiten werden nie veralten, und mit KI werden sie wertvoller denn je.

Was ich mir fuer die naechsten 20 Jahre wuensche

Wenn ich in zwanzig Jahren auf diesen Artikel zurueckblicke, hoffe ich, dass ich sagen kann: Die besten Jahre lagen noch vor mir. Die Softwareentwicklung ist ein Feld, das sich staendig neu erfindet, und genau das macht sie so faszinierend. Von Mainframes zu Cloud, von Wasserfall zu Agile, von manueller Programmierung zu KI-gestuetzter Entwicklung — jede Aera hat neue Moeglichkeiten eroeffnet.

Ich bin gespannt, was als Naechstes kommt. Und ich bin dankbar fuer jede Lektion, die ich auf dem Weg dorthin gelernt habe.