Two ways of asking the same question.
Both halves of what I do come down to: what happens when this fails, and how do I keep that from mattering.
I studied Control and Instrumentation Engineering, which is a formal way of saying I spent several years learning how physical systems misbehave, and how to write logic that keeps them from doing that too often. PID loops, plant models, ladder logic, the occasional sensor that lies to you under the wrong conditions.
Somewhere alongside that, I picked up the other half of what's here: the software and automation work that keeps information moving with the same discipline. A fire alarm system doesn't care whether the failure is a burnt-out sensor or a dropped MQTT packet — it just has to still work. I've found that's just as true of an automation pipeline or a content system with no operator watching it.
Most of what interests me sits in that overlap: tracing a fault back to its actual cause instead of the first plausible one, weighing edge versus cloud the same way I'd weigh a quick script against a full service, and building in the retry logic or fallback path before something forces the issue. The tools differ. The judgment doesn't.
Outside of the two tracks above, I've also spent time on the more commercial side of digital work — site structure, search performance, that kind of thing — which is where the Digital Systems track comes from.
Background
Prefer the long version? Download the full resume (PDF) — add your file and link here.