Sieben Jahre Code — und warum es jedes Jahr besser wird
Eine kurze, ehrliche Zwischenbilanz: was sich seit 2017 in meinem Engineering-Alltag verändert hat, was ich heute anders mache als mit 19 — und worauf ich Anfänger immer wieder hinweise.
2017 war ich 19 und schrieb Minecraft-Plugins, die fast nie funktionierten, wenn ich sie gerade nicht ansah. Heute, sieben Jahre später, schreibe ich Software, die ohne mich läuft. Dazwischen liegt nicht nur Erfahrung — dazwischen liegen ein paar Gewohnheiten, die ich rückblickend gerne früher gehabt hätte.
Das, was ich am meisten unterschätzt habe
Mit 19 dachte ich, der Unterschied zwischen einem guten und einem schlechten Entwickler liegt im Wissen. Wer mehr Frameworks kennt, gewinnt. Heute weiß ich, dass es im Schreibstil liegt — in der Frage, ob du in der Lage bist, Code so zu schreiben, dass die Person, die ihn in zwei Jahren liest (meistens du selbst), nicht eine Stunde braucht, um zu verstehen, was er tut.
Klingt banal. Ist aber das, was ich heute in fast jedem Code-Review aufschreibe.
Drei Gewohnheiten, die alles verändert haben
Erstens: Ich schreibe Tests vor dem Refactoring. Nicht TDD im strikten Sinne — eher als Sicherheitsnetz. Bevor ich eine größere Änderung anfasse, baue ich einen Test, der den bestehenden Zustand fixiert. Dann darf ich brechen, was ich will. Das hat meine Refactoring-Geschwindigkeit ungefähr verdreifacht und meine Refactoring-Angst auf null reduziert.
Zweitens: Ich schreibe Architecture Decision Records. Eine Markdown-Datei pro tragender Entscheidung, drei Absätze: Kontext, Entscheidung, Konsequenzen. Ich brauche diese Notiz vier Jahre später — wenn ich oder ein anderer Entwickler in der Codebase sitzt und sich fragt, „warum haben die das damals so gebaut?". Die Antwort ist dann da.
Drittens: Ich frage öfter „brauchst du das wirklich?". Mit 22 hätte ich jeden Wunsch des Auftraggebers ausgebaut. Heute schaue ich mir die Anforderung an, denke an die Pflege der nächsten zwei Jahre und sage manchmal: „Wir können das bauen. Aber willst du es wirklich? Hier ist eine kleinere Lösung, die 80 % deines Problems löst und ein Drittel des Codes erfordert." Diese Frage hat mehr Vertrauen aufgebaut als jede technische Demo, die ich je gemacht habe.
Was ich Anfängern sage
Wenn jemand mit 19 anfängt, wie ich es getan habe, ist die wichtigste Lektion: Liefere etwas, das funktioniert, und liefere es früh. Wartet nicht auf den perfekten Stack, das perfekte Setup, das perfekte Verständnis. Liefert ein Plugin, das eine einzige Sache tut. Liefert eine Website mit einer einzigen Seite. Liefert einen Pull Request mit einem einzigen Commit.
Die Leute, von denen ihr lernen wollt, sind nicht die, die viel wissen — es sind die, die viel geliefert haben.
Und wenn das geliefert ist: schreibt darüber. Auch wenn nur drei Leute es lesen. Schreiben zwingt euch zum Verstehen. Diese drei Absätze, die euch jetzt unangenehm sind, sind in zwei Jahren das, was euch eine Anfrage einbringt, die ihr ohne sie nie bekommen hättet.
Warum es jedes Jahr besser wird
Mit 26 finde ich Software-Entwicklung erst richtig interessant. Die ersten paar Jahre waren ein endloses Aufholen — neue Sprachen, neue Frameworks, neue Patterns. Heute fühlt sich vieles vertraut an, und gerade deshalb kann ich aufhören, der ständige Anfänger zu sein, und anfangen, auszuwählen, was ich in ein Projekt einbaue.
Das macht den Unterschied zwischen einem Junior, der jedes neue Tool einbaut, und einem Engineer, der weiß, warum er auf 80 % des Hype-Stacks verzichtet. Beide schreiben Code. Nur einer hinterlässt eine Codebase, die in fünf Jahren noch wartbar ist.
Auf die nächsten sieben.