// personal
Critical Dependencies
I build systems for a living. Turns out the most important one was already built around me.
Every project has dependencies. If you've spent more than five minutes in a terminal, you know the drill. You type npm install and watch 847 packages cascade down your screen like the world's most boring waterfall. Half of them are packages you've never heard of, maintained by someone who abandoned the repo in 2019 and is presumably living off the grid now. You don't question it. You just hope nothing breaks.
I've spent most of my career obsessing over this stuff. Pinning versions. Auditing vulnerability reports. Making sure the thing I'm building doesn't collapse because some transitive dependency four layers deep decided to mass-delete itself on a Tuesday. You learn to be self-reliant. You build redundancy. You write the script yourself because trusting someone else's package feels like handing a stranger your house keys and hoping they don't reorganize your kitchen.
That's the mentality, anyway. The lone engineer mythology. Handle it yourself. Stay late. Figure it out. Your uptime is your identity.
Then your body throws a 500 Internal Server Error and suddenly none of that matters.
The Outage
I'm not going to get into the medical play-by-play. The short version is that my heart decided to stage an unscheduled outage, and for the first time in my life, I couldn't troubleshoot my way out of it. There was no hotfix. No rollback. No "let me SSH in real quick and restart the service." Just me, flat on my back, staring at a ceiling I didn't recognize, realizing that the system I'd neglected the most was the one running me.
Here's where I'd normally pivot to a lesson about monitoring your health metrics, and yeah, do that. But that's not actually what got me through this. What got me through this was something I've spent my whole career undervaluing.
My dependencies.
Not the kind you install. The kind that install themselves into your life so quietly you forget they're load-bearing.
The Runtime Environment
My wife. I don't have the vocabulary for what she did. And I've sat through enough technical writing reviews to know that when you can't find the right words, the subject is bigger than the document. She became the project manager, the sysadmin, and the incident commander all at once. She tracked medications, interrogated doctors with the intensity of a senior engineer reviewing a pull request, and somehow kept our household running while I was busy being the least useful person in a hospital bed.
She didn't just hold things together. She was the thing holding things together. The entire runtime environment. If she goes down, nothing works. Nothing.
The Uptime Monitor
My kids. They don't know it, but they were the uptime monitor. The reason you keep the system running. There's a specific kind of motivation that hits different when the people depending on your deployment are small humans who think you're invincible.
You want to stay online for them. Not in the "answer Slack messages at midnight" sense. In the "be physically present on this planet for as long as possible" sense. They made me want to get better with a force I can't quantify, and I've tried to quantify everything in my life.
The Failover Cluster
And then, honestly, my employer. I know how that reads. "Company cares about employee" sounds like a LinkedIn post ghostwritten by HR. But I need to say this because it's true, and because the opposite story is far more common.
When I went down, they didn't send a "get well soon" message and quietly start backfilling my role. They checked in. They covered my responsibilities without making me feel like I was falling behind. They made it clear, in actions and not just words, that the human being mattered more than the headcount. I've worked places where taking a sick day felt like a performance review. This was not that. And it made a difference I didn't expect.
The Architecture Was Already There
I'm a person who builds systems for a living. I harden images. I lock down configurations. I write scripts that account for seventeen edge cases before breakfast. I plan for failure because failure is always one misconfigured policy away.
But I never dependency-mapped my own life.
If I had, I would have seen it sooner. The architecture was already there. My wife handling the load balancing. My kids providing the reason to maintain five-nines availability. My company absorbing the traffic while the primary node was down. None of these are nice-to-haves. They're core services. Without them, the whole stack falls over.
I'm recovering now. Taking it slower, which if you know me, is roughly as natural as asking a firewall to be more permissive. But I'm doing it. Not because some doctor told me to, though they did, repeatedly, with increasing firmness. I'm doing it because those dependencies deserve a system that's actually maintained. Not one running on caffeine and stubbornness with an uptime that's held together by duct tape and denial.
No Clever Callback
So this is the part of the blog post where I'm supposed to tie it all together with something clever. Some callback to package.json or a joke about heartbeat --interval checks. And yeah, I thought about it. I had a whole bit planned about writing a HEALTHCHECK Dockerfile instruction for my cardiovascular system.
But I think I'll just say this instead.
Check your dependencies. Not the ones in your lock file. The ones in your life. The people who show up when your system goes critical. The ones who don't need a README to know what to do. The ones who were load-bearing this whole time while you were busy thinking you were running the whole thing solo.
They're not optional. They never were.
And if you're lucky enough to have them, maybe don't wait for a 500 to tell them.
"Critical Dependencies" - I build systems for a living. Turns out the most important one was already built around me.
A heart attack taught me that the most critical dependencies in my life were never in a lock file. They were the people who showed up when my system went down.
michaelroberts.me
Top comments (0)