Als ich mich bei CHECK24 bewarb, habe ich in der Coding-Challenge Zod eingesetzt, um die Eingaben zu validieren. Das ist aufgefallen. Später erfuhr ich, dass mein künftiger Team-Lead genau diese Type-Safety-Gewohnheit bemerkt und sich für mich eingesetzt hatte. Ich war noch im Studium und landete in seinem Team, wo ich Versicherungsvergleiche in React, TypeScript und PHP/Symfony baute.
Angefangen hat es aber nicht dort. Meinen ersten professionellen Entwicklerjob hatte ich mit neunzehn bei homevoice, wo ich mit React und Spring Boot Software für die Hausverwaltung entwickelte. Rund um das Studium war ich außerdem freiberuflich tätig und baute Websites für Künstler:innen und kleine Unternehmen. Dabei habe ich gelernt, technische Möglichkeiten und Grenzen für fachfremde Kund:innen klar zu erklären. CHECK24 verließ ich mit einem guten Zeugnis und der Option, jederzeit zurückzukommen, und wechselte dann zu BuildlinX, wo ich heute Architekturverantwortung für ausgewählte Produktbereiche trage: vom Web-Frontend über das Backend bis zu den Edge-Systemen, in TypeScript und Go.
In meinen eigenen Projekten beschäftige ich mich viel mit dem TypeScript-Ökosystem. Ich mag es, ein System so zu verdrahten, dass eine Änderung am Datenbankschema als Typfehler im Frontend auftaucht, wo der Fehler zur Compile-Zeit sichtbar wird statt auf dem Bildschirm von Nutzenden. Zuletzt heißt das vor allem Effect, mit dem ich modulare, zusammensetzbare TypeScript-Anwendungen strukturiere. Typisierte Fehler und Dependency Injection sind dabei nur ein Teil, nicht der ganze Sinn. Ich halte es aktuell für das stärkste Fundament, das TypeScript für diese Art von Architektur bietet, bin dabei aber nicht dogmatisch: Ich suche noch die Grenze, wo sich der Aufwand lohnt und wo er übertrieben ist.
Inzwischen wird ein großer Teil meines Implementierungscodes von KI-Agenten geschrieben, meist von Codex. Meine Aufmerksamkeit gilt den Teilen, die darüber entscheiden, ob Software etwas taugt: das Problem verstehen, die Architektur wählen, die Grenzen ziehen und das Ergebnis an denselben Ansprüchen an Reviews, Tests, Typen und Wartbarkeit messen, die ich in der gesamten Codebase stelle. Die Werkzeuge werden immer besser, und ich will immer besser darin werden, sie zu steuern und zu prüfen.
