Ich habe nicht in der Systemarchitektur angefangen. Ich habe im Grafikdesign angefangen, habe genommen, was an Arbeit kam, und das Geschäft in der Nähe von Kunden gelernt, die etwas brauchten und es nicht genau beschreiben konnten.
Design lehrte mich den Teil der Arbeit, den ingenieurwissenschaftliche Ausbildung oft überspringt: Ein Ergebnis ist nur gut, wenn es das Problem löst, das der Kunde tatsächlich hat — und das ist selten das zuerst genannte. Bis zur echten Anforderung vorzudringen — durch Fragen, Skizzen und ein paar billige Irrtümer — ist dieselbe Fähigkeit, ob das Ergebnis ein Logo oder ein Datenmodell ist.
Der Übergang geschah allmählich und aus unspektakulären Gründen. Kunden fragten immer wieder nach Dingen, die sich mit keiner Designdatei lösen ließen. Sie brauchten einen Buchungsablauf, dann eine Bestandsverfolgung, dann eine Erklärung, warum zwei Berichte sich widersprachen. Jede Antwort verlangte, eine Schicht tiefer zu gehen, bis die Arbeit keine Dekoration auf einem System mehr war, sondern das System selbst.
Am stärksten änderte sich der Zeithorizont. Ein Design wird bei der Auslieferung beurteilt. Ein System wird jahrelang beurteilt, von Menschen, die beim ursprünglichen Gespräch nicht dabei waren, unter Bedingungen, die niemand vorhergesehen hat. Das verschiebt die Prioritäten: klar benennen, Module wirklich trennbar halten, aufschreiben, warum eine Entscheidung fiel, und nicht nur, was entschieden wurde. Was am ersten Tag nach Mehraufwand aussieht, macht den dreißigsten Monat beherrschbar.
Die Freelance-Jahre erwiesen sich als die nützliche Vorbereitung, nicht als Umweg. Alles selbst zu machen — das Angebot, den Zuschnitt, die Umsetzung, die Rechnung, das unangenehme Gespräch, wenn etwas verrutscht ist — lehrt, wo Projekte wirklich brechen. Es ist selten der Code. Es ist die Lücke zwischen dem, was versprochen, dem, was verstanden, und dem, was gebraucht wurde.