Somewhere in the middle of the Fargo years, the ground under the work shifted: servers stopped being machines you could point at and became AWS consoles you could architect in. I got to stand that world up from nothing — real cloud architecture for real clients, in an era when “we’re moving to the cloud” was still a sentence that made rooms nervous.

Learning AWS in the mid-2010s was drinking from a hose that kept adding nozzles. Services multiplied yearly; best practices had a shelf life of months; and the console would happily let you build something expensive, insecure, and wrong with total confidence. (Eventually I formalized it — I carry two AWS certifications — but the exams came long after the scar tissue. The certs proved the knowledge; the 2 a.m. pages produced it.)

Infrastructure work rewires how you see software. Application developers think in features; infrastructure makes you think in failure domains — what dies together, what recovers alone, what the blast radius of any one mistake is. Once that lens installs, it never uninstalls. It’s why I can’t look at a website today without asking where it lives, what its backup story really is, and who gets paged when it falls over — the application is the visible third of the iceberg, and rescues are almost always about the underwater part.

The cloud years also taught the discipline of writing it down. An architecture that lives in one person’s head is a hostage situation waiting to happen — I’ve since seen that movie from the rescue side more times than I can count, and the villain is never malice; it’s always undocumented competence walking out a door. Tape every show. The infrastructure version of that rule got taped into me here.

Mostly, though, this chapter is where the job description quietly outgrew “developer.” Mobile, web, cloud, whatever the client’s problem was shaped like — the trade I was actually learning was systems. Fargo doesn’t let you be precious about your lane.

Next: The person who answers — what leading projects actually means.