Morgan Helton
Morgan Helton is a software engineer at Flox, working on cloud infrastructure and systems reliability. With prior experience in industrial controls and instrumentation and two decades of Linux and open-source use, Morgan blends practical engineering discipline with modern cloud-native practices.
Session
My father-in-law buys salvage cars, fixes them up, and sells them with real pride in the work, but the family cars always have a check engine light on. It's not that he doesn't care; he knows he can fix anything that breaks, so the urgency never lands. Many engineering teams treat their internal tools the same way.
These teams ship to their customers with pipelines, versioning, and signed releases, but ship to themselves through PATH hacks, Slack threads of curl | bash, SSH access to a specific box that builds the binary nobody else can rebuild, and S3 buckets of artifacts that nobody owns after the engineer who wrote the original leaves. The xz utils backdoor and the recent VS Code extension compromise that breached GitHub itself should have shifted the calculus, but the patterns persist anyway because the engineering equivalent of a check engine light still feels tolerable.
The talk walks these patterns using firsthand examples from a few teams and language ecosystems I've worked in, and digs into what makes them so persistent. The audience walks away with vocabulary for the patterns and a sharper read on why engineering orgs keep tolerating them.