Wenn ich auf meinen bisherigen beruflichen Weg zurückblicke, zieht sich ein Gedanke ziemlich konsequent hindurch: Ich wollte nie an dem Punkt stehenbleiben, an dem ich gerade angekommen war. Damit meine ich nicht, dass ich ständig den nächsten Titel, die nächste Position oder möglichst viele unterschiedliche Technologien sammeln wollte. Mir ging es vielmehr darum, meine Arbeit immer wieder aus einer neuen Perspektive kennenzulernen und dadurch besser zu verstehen, was eigentlich vor, während und nach der Entwicklung einer Software passiert.
Technische Weiterentwicklung war dabei immer wichtig, aber sie war für mich nie die einzige Form von Entwicklung. Ich wollte genauso verstehen, wie Testing auf Software schaut, welche Probleme im Helpdesk sichtbar werden, was der Betrieb von einer Anwendung benötigt, wie Anforderungen im Consulting entstehen und weshalb ein technisch gutes Produkt im Vertrieb trotzdem schwer vermittelbar sein kann.
Mein heutiger Blick auf Software ist deshalb stark von diesen unterschiedlichen Stationen geprägt. Viele Entscheidungen, die ich heute bei KI-gestützter Entwicklung treffe, lassen sich wahrscheinlich besser verstehen, wenn man weiß, dass ich Software nie ausschließlich aus der Perspektive des Programmierens betrachten wollte.
Neue Technologie allein war für mich nie genug
In der IT gibt es praktisch immer etwas Neues zu lernen. Programmiersprachen verändern sich, Frameworks kommen und gehen, Betriebssysteme entwickeln sich weiter und Technologien, die gestern noch unverzichtbar erschienen, spielen einige Jahre später vielleicht nur noch eine Nebenrolle.
Es wäre deshalb relativ einfach gewesen, Weiterentwicklung ausschließlich darüber zu definieren, ständig die nächste Technologie zu lernen.
Natürlich habe ich genau das ebenfalls getan, denn ohne technische Neugier kommt man in diesem Beruf kaum weit. Trotzdem habe ich irgendwann gemerkt, dass zusätzliche technische Tiefe allein meinen Blick auf Software nicht unbedingt vollständiger macht.
Ich kann eine Programmiersprache sehr gut beherrschen und trotzdem eine Anwendung bauen, die niemand gerne benutzt.
Ich kann eine technisch hervorragende Architektur entwickeln und trotzdem am eigentlichen Problem vorbeiarbeiten.
Ich kann alle Tests grün bekommen und dennoch eine Software ausliefern, die sich im Betrieb schlecht warten lässt.
Technisches Können bleibt notwendig, aber es beantwortet eben nicht jede wichtige Frage.
Deshalb wollte ich die angrenzenden Bereiche verstehen
Mich hat zunehmend interessiert, wie Software aussieht, wenn man nicht gerade selbst an ihrem Code arbeitet.
Entwicklung, Testing, Helpdesk, Betrieb, Consulting und Vertrieb stellen an dasselbe Produkt völlig unterschiedliche Fragen, und genau diese unterschiedlichen Blickwinkel wollte ich kennenlernen.
Im Testing geht es nicht darum, eine eigene Lösung zu verteidigen, sondern bewusst nach Situationen zu suchen, in denen sie nicht funktioniert.
Im Helpdesk zeigt sich, wie Benutzer eine Anwendung tatsächlich verstehen und an welchen Stellen die Vorstellung der Entwicklung nicht mit der Realität zusammenpasst.
Im Betrieb zählt nicht nur, ob eine Funktion heute funktioniert, sondern ob die Anwendung zuverlässig läuft, aktualisiert werden kann und sich Fehler nachvollziehen lassen.
Im Consulting beginnt die Arbeit häufig lange vor der technischen Lösung, weil zunächst verstanden werden muss, welches Problem überhaupt gelöst werden soll.
Und im Vertrieb reicht es nicht aus, technisch erklären zu können, was ein Produkt kann. Der Nutzen muss für jemanden verständlich werden, der sich nicht für die innere Architektur interessiert.
Diese Erfahrungen haben meinen Blick auf Entwicklung stärker verändert als manches neue Framework.
Manche Wechsel waren deshalb ganz bewusst
Wenn ich mich beruflich verändert habe, ging es mir nicht ausschließlich darum, eine ähnliche Aufgabe bei einem anderen Arbeitgeber unter anderen Bedingungen weiterzuführen. Ein Wechsel war für mich besonders dann interessant, wenn ich dabei etwas lernen konnte, das mir bisher fehlte.
Das konnte technisches Wissen sein, aber genauso eine neue Rolle oder ein anderer Blick auf denselben Entwicklungsprozess.
Natürlich bedeutet das auch, eine vertraute Position zu verlassen. Sobald man eine Aufgabe gut beherrscht, wird sie angenehm. Man kennt die typischen Probleme, weiß, welche Werkzeuge funktionieren, und kann viele Entscheidungen aus Erfahrung treffen.
Genau dort entsteht aber auch die Gefahr, dass Lernen langsamer wird.
Ich wollte deshalb immer wieder bewusst Situationen haben, in denen ich nicht schon alles kannte.
Nicht weil Unsicherheit an sich erstrebenswert wäre, sondern weil ich dabei normalerweise am meisten gelernt habe.
Persönliche Weiterentwicklung gehörte für mich genauso dazu
Berufliche Entwicklung wird in der IT häufig stark technisch beschrieben. Man lernt eine neue Sprache, übernimmt mehr Verantwortung oder arbeitet irgendwann an größeren Systemen.
Für mich gehört dazu aber genauso, wie man mit Menschen arbeitet, wie man technische Entscheidungen erklärt, wie man Anforderungen hinterfragt und wie man mit Situationen umgeht, in denen es keine eindeutig richtige technische Antwort gibt.
Gerade Consulting und Vertrieb haben mir an dieser Stelle Dinge beigebracht, die sich nicht über eine neue Bibliothek lernen lassen.
Eine technisch korrekte Erklärung ist beispielsweise nicht automatisch eine gute Erklärung.
Eine Lösung, die ich für offensichtlich sinnvoll halte, wirkt auf einen Kunden möglicherweise vollkommen anders, weil er andere Prioritäten besitzt.
Und ein Gespräch ist nicht dann erfolgreich, wenn ich möglichst viel Fachwissen untergebracht habe, sondern wenn am Ende beide Seiten dasselbe Problem verstanden haben.
Diese Erfahrungen spielen heute sogar bei meiner Arbeit mit KI wieder eine Rolle.
Die vielen Fragen an ChatGPT sind für mich kein Zufall
Heute beginne ich größere Themen häufig damit, mir in ChatGPT sehr viele Fragen stellen zu lassen. Auf den ersten Blick wirkt das wie eine völlig neue KI-Arbeitsweise, tatsächlich steckt darin aber viel von dem, was ich über Jahre in anderen Rollen gelernt habe.
Bevor ich eine Lösung baue, möchte ich möglichst gut verstehen, welches Problem überhaupt vorliegt.
Ich möchte wissen, welche Annahmen ich getroffen habe, welche Randbedingungen existieren und wo noch Entscheidungen fehlen.
Das erinnert deutlich stärker an gute Anforderungsanalyse und Consulting als an klassisches Programmieren.
Die KI verändert dabei vor allem die Geschwindigkeit und den Aufwand. Ich kann einen Gedanken sehr ausführlich auseinandernehmen, ohne dafür jedes Mal mehrere Personen zu einem Workshop zusammenbringen zu müssen.
Die grundlegende Haltung dahinter ist aber älter als ChatGPT.
Erst verstehen, dann bauen.
Auch mein Testing kommt aus früheren Erfahrungen
Dasselbe gilt für meinen heutigen Ansatz bei automatisierten Tests.
Meine Tests sollen nicht nur bestätigen, dass eine Funktion im vorgesehenen Standardfall funktioniert. Sie sollen möglichst Situationen finden, in denen die Umsetzung nicht hält, was die Spezifikation verspricht.
Dieser Gedanke entsteht nicht deshalb, weil KI gerade modern ist.
Er stammt aus der Testerperspektive, die ich schon lange vor Codex kennengelernt habe.
Neu ist lediglich, dass ich heute einen Teil dieser Arbeit automatisieren kann und dadurch als Einzelunternehmer einen Umfang an Tests anstreben kann, der früher einen erheblich größeren manuellen Aufwand bedeutet hätte.
KI verstärkt damit teilweise Arbeitsweisen, die ich schon vorher für sinnvoll gehalten habe.
Stillstand bedeutet für mich nicht, dieselbe Technologie lange zu benutzen
Ich würde allerdings auch nicht behaupten, dass man ständig Technologien wechseln muss, um sich weiterzuentwickeln.
Manchmal steckt die größere Entwicklung gerade darin, eine Technologie lange genug zu benutzen, um ihre schwierigen Seiten wirklich kennenzulernen.
Ein System drei Jahre zu betreiben, vermittelt andere Erfahrungen als ein schneller Prototyp.
Eine Software über viele Versionen weiterzuentwickeln zeigt andere Probleme als ein komplett neues Projekt.
Und ein technischer Ansatz, der auf dem Papier hervorragend aussieht, kann nach Jahren im Betrieb ganz anders bewertet werden.
Für mich ist deshalb nicht entscheidend, ständig etwas Neues zu benutzen.
Entscheidend ist, weiterhin neue Dinge zu lernen.
Das kann genauso gut innerhalb eines bekannten Systems passieren.
KI ist für mich deshalb die nächste große Veränderung, aber nicht die erste
Heute verändert KI meine Arbeit stärker als viele einzelne Technologien zuvor. ChatGPT und Codex übernehmen inzwischen sehr unterschiedliche Teile meines Arbeitsprozesses, und mit Agenda versuche ich sogar, die eigentliche technische Umsetzung zunehmend zu orchestrieren.
Trotzdem empfinde ich diese Entwicklung nicht als völligen Bruch mit allem, was vorher war.
Eigentlich setzt sie meinen bisherigen Weg fort.
Wieder verändert sich die Frage, welche Fähigkeiten ich selbst brauche.
Wenn Codex immer mehr konkrete Implementierung übernimmt, wird das reine Tippen von Code für mich weniger zentral. Dafür werden Architekturverständnis, gute Anforderungen, Bewertung von Ergebnissen, Testing, Betrieb und fachliche Entscheidungen wichtiger.
Genau diese Bereiche wollte ich schon lange vorher verstehen.
Im Rückblick war das vermutlich eine ziemlich gute Vorbereitung auf eine Entwicklung, die damals noch gar nicht absehbar war.
Ich möchte auch mit KI nicht stehenbleiben
Es wäre leicht, jetzt einen Punkt zu erreichen, an dem ich sage: Diese Arbeitsweise funktioniert, also benutze ich sie von nun an einfach unverändert weiter.
Genau das möchte ich aber wieder nicht.
Meine heutigen Prozesse sind an vielen Stellen noch nicht fertig. Testing ist nicht unabhängig genug, parallele Arbeit muss besser koordiniert werden, automatische Deployments fehlen noch in Teilen und langfristig möchte ich einen erheblichen Teil meiner KI-Arbeit auf eigene lokale Systeme verlagern.
Auch Agenda verändert sich ständig mit meinen Erfahrungen.
Das bedeutet zwangsläufig, dass manche Entscheidungen, die ich heute für richtig halte, in einigen Jahren vielleicht überholt wirken.
Damit kann ich gut leben.
Weiterentwicklung bedeutet für mich nicht, jederzeit die perfekte Lösung zu kennen.
Sie bedeutet, bereit zu sein, eine funktionierende Lösung wieder infrage zu stellen, wenn sich die Rahmenbedingungen verändert haben.
Der rote Faden ist deshalb nicht eine bestimmte Technologie
Wenn ich meinen beruflichen Weg irgendwann nur anhand von Programmiersprachen, Produkten und Arbeitgebern beschreiben würde, wäre das zwar chronologisch korrekt, würde aber aus meiner Sicht das Wichtigste verpassen.
Der eigentliche rote Faden ist für mich die Neugier auf den nächsten Blickwinkel.
Was passiert außerhalb meines eigenen Bereichs?
Warum arbeitet eine andere Rolle anders?
Welches Problem sieht jemand, das ich aus meiner Perspektive übersehe?
Und welche Fähigkeiten fehlen mir, um das Gesamtbild besser zu verstehen?
Diese Fragen haben mich durch sehr unterschiedliche Bereiche geführt und sind heute immer noch dieselben.
Nur dass ich sie inzwischen häufig zuerst ChatGPT stelle.