Bevor ich Software-Architekt war, war ich der Typ, der das Netzwerk in einem Gaming-Center in Amman reparierte. Davor war ich Verkäufer und Kassierer in einem Computerladen. Ich war 17, als ich anfing, 22, als ich diese Welt verließ, um meinen CIS-Abschluss zu machen und professionell Software zu bauen.

In Job-Interviews erzähle ich diesen Teil meines Hintergrunds nicht zuerst. Aber ich denke ständig daran. Er hat geprägt, wie ich Systeme debugge, wie ich über Zuverlässigkeit nachdenke und wie ich mit Nicht-Engineers über technische Probleme spreche — mehr als jeder Job seitdem.

Explosion Network Gaming Centre, 2007–2009

Der Jobtitel war Netzwerkadministrator und Manager. In der Praxis: Ich verwaltete das Netzwerk, kümmerte mich um das Geld, betreute die Maschinen, bediente die Kunden und sperrte gelegentlich Spieler für Cheating bei Counter-Strike.

Ja, ich war der Typ, der Spieler für Cheating bei Counter-Strike gesperrt hat. Ich bereue nichts.

Das Netzwerk war ein physisches LAN — Kabel, Switches, DHCP, ein Router zum ISP und etwa 30 Windows-XP-Maschinen, die dauerhaft und hart genutzt wurden von Teenagern, die null Verständnis für Uptime-Fenster hatten. Wenn etwas kaputt war, musste es jetzt repariert werden. Nicht “wir adressieren das im nächsten Sprint.” Nicht “lass mich ein Ticket eröffnen.” Jetzt. Die Person am Tresen wartete, die Uhr lief (wir berechneten stundenweise), und ich war das gesamte Ops-Team.

Dieser Druck ist nicht stressig auf die Art, wie On-Call bei einem Tech-Unternehmen stressig ist. Er ist einfacher und unmittelbarer: ein echter Mensch steht vor dir und verliert Geld, weil die Maschine an Station 12 den Game-Server nicht erreicht. Fix es.

Was ein physisches LAN dir beibringt, was AWS nicht kann

Wenn das Netzwerk aus Kabeln besteht, die du anfassen kannst, hört das Netzwerk auf, abstrakt zu sein. “Die Verbindung ist down” bedeutet etwas Konkretes. Es bedeutet: ist das Kabel eingesteckt? Leuchtet der Switch-Port? Ist der DHCP-Lease frisch? Hat jemand wieder über das Kabel hinter dem Wandpanel gestolpert?

Ich habe ein Netzwerkproblem gelöst, indem ich physisch die Länge eines Kabels entlangging, öfter als ich zählen kann. Das ist eine Skill, die auf keinem LinkedIn-Profil auftaucht. Aber sie ist absolut die Grundlage des Instinkts, den ich habe, wenn in einem verteilten System etwas falsch ist: das Problem ist irgendwo Konkretes. Finde es. Rate nicht vom Dashboard aus; trace den Pfad.

Die meisten Engineers, mit denen ich gearbeitet habe, die direkt aus dem Studium in Cloud-Infrastruktur gegangen sind, haben ein mentales Modell vom “Netzwerk” als API. Du rufst es auf, es antwortet (meistens). Wenn es nicht antwortet, liest du die CloudWatch-Logs. Das ist in Ordnung. Es funktioniert. Aber du verlässt dich auf jemand anderes Modell davon, was das Netzwerk macht.

Wenn du ein Kabel verfolgt hast, hast du ein anderes Modell. Netzwerke sind physische Dinge mit Fehlerpunkten, die oft peinlich banal sind. Ein Spanning-Tree- Loop, der einen Gaming-Saal an einem Freitagabend lahmlegte, ist dieselbe Klasse von Problem wie eine BGP-Fehlkonfiguration, die eine Datacenter-Region außer Betrieb nimmt — die Topologie versagte auf eine vorhersehbare Art, die jemand hätte voraussehen sollen. Die Peinlichkeit skaliert, aber die Kategorie ändert sich nicht.

Die Kassierer-Jahre und was Geld durch die Hände lehrt

Vor dem Gaming-Center war ich bei Collection Computer Systems: Computer verkaufen, Bargeld annehmen, einfache PC-Wartung machen. Ich war 17.

Geld zu handhaben verändert, wie man über Wert denkt. Nicht im philosophischen Sinne — in einem sehr wörtlichen. Man entwickelt ein Gespür dafür, wann ein Kunde kurz davor ist zu gehen, was eine vernünftige Marge bei einem Verkauf tatsächlich ist, warum ein Produkt, das sich nicht in 30 Sekunden erklären lässt, nie aus einem Einzelhandelsboden heraus verkauft werden wird, egal wie technisch überlegen es ist.

Ich war in Engineering-Meetings, in denen jemand eine Lösung präsentiert, die klar korrekt ist — technisch rigoros, gut belegt, offensichtlich der richtige Call — und zusieht, wie sie stirbt, weil niemand im Raum sie mit dem verbunden hat, was das Business zu tun versuchte. Das ist ein Kommunikationsfehler, kein technischer. Die Engineers, die Wege genommen haben, die einen Kunden auf der anderen Seite einer Theke einschlossen, haben das typischerweise früher und direkter gelernt als die, die direkt in die Entwicklung gegangen sind.

Der Kunde ist keine User-Story. Der Kunde ist eine Person, die gehen kann. Alles downstream davon — die Architektur, die Uptime, die Feature-Priorisierung — steht im Dienst daran, dass diese Person einen Grund hat zu bleiben.

Der Teil, den Leute nicht erwarten: MUMPS, 2010

Nach dem OSS-Club, nach meinem Abschluss, ging ich zu EHS/HAKEEM — Jordaniens nationales Healthcare-System — und verbrachte Zeit damit, MUMPS-Routinen auf VistA zu schreiben. MUMPS, falls du nicht vertraut bist: eine Sprache aus dem Jahr 1966, läuft immer noch Krankenhaussysteme auf der ganzen Welt, berühmt kryptisch, berühmt wichtig.

Ich bringe das im Kontext des ungewöhnlichen Wegs auf, weil es eine weitere Schicht desselben Dings ist: die Leute, die Healthcare-Software schreiben, die 30 Jahre lang läuft, haben eine andere Beziehung zu Korrektheit als Leute, deren Deployment-Pipeline Rollbacks handhabt. In einem System, in dem falscher Output klinische Konsequenzen hat, ist die Definition von “fertig” anders. Man shippt nicht einfach und schaut, was passiert.

Das Gaming-Center lehrte mich: fix es jetzt, der Kunde wartet. MUMPS lehrte mich: sei sehr sicher, was du tust, der Patient hängt davon ab. Beides ist richtig. Sie stehen in Spannung, und meine gesamte Karriere handelt davon, diese Spannung in Kontexten zu navigieren, die irgendwo zwischen diesen beiden Polen liegen.

Was der ungewöhnliche Weg wirklich wert ist

Ich war auf der Ops-Seite der Theke in einer Weise, wie es die meisten Architekten nie waren. Ich habe das Kabel in den Händen gehalten, das das Problem verursachte. Ich habe einem Teenager erklärt, warum sein Konto gesperrt wurde, in Worten, die technisch korrekt und gleichzeitig verständlich waren. Ich habe Bargeld für etwas genommen, das ich gebaut (oder repariert) hatte, und sofort verstanden, ob es den Preis wert war.

Das sind nicht die Skills auf meinem Lebenslauf. Es sind die Skills unter den Skills auf meinem Lebenslauf.

Was ich bei Engineers bemerke, die Wege wie meinen gegangen sind, ist eine spezifische Art von Sturheit gegenüber Root Causes. Wenn etwas kaputt ist, gibt es eine physische Sache, die es verursacht. Kein Vibe, keine vage Misskommuni- kation zwischen Services — eine Sache. Finde die Sache. Das LAN-Kabel war entweder eingesteckt oder nicht. Diese Epistemologie skaliert überraschend gut auf verteilte Systeme.

Das Andere: Geduld mit nicht-technischen Stakeholdern. Wenn du einem Elternteil erklärt hast, warum das Konto seines Kindes gesperrt wurde, oder einem Kunden erklärt hast, warum der Computer, den er will, teurer ist als der in der Anzeige, hast du geübt, technische Entscheidungen an Menschen zu erklären, die Skin im Spiel haben, aber nicht den Kontext. Das ist ein großer Prozentsatz davon, was ein Senior Engineer in einer halbwegs komplexen Organisation macht.

Ich denke nicht, dass jeder als Kassierer anfangen muss, um ein guter Architekt zu werden. Aber ich denke schon, dass Engineers, die auf der empfangenden Seite eines Systems waren — die die Person waren, deren Erfahrung davon abhing, ob das Netzwerk funktioniert — etwas tragen, das sich von der anderen Seite der Tastatur allein nur sehr schwer aneignen lässt.

Mein Weg war Einzelhandel → Gaming-Center-Netzwerkadmin → MUMPS → verteilte Systeme. Es ist kein Playbook. Es ist meins, und ich würde es nicht für die gerade Linie tauschen.