DEV Community: Michael Roberts

"Critical Dependencies"

Michael Roberts — Sat, 04 Apr 2026 09:19:57 +0000

// 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

Building NeonAIX: Or How I Accidentally Learned How AI Actually Works

Michael Roberts — Thu, 15 Jan 2026 04:26:57 +0000

How This Started (aka Mild Annoyance)
I’ve been building things on the web for a long time. Servers, tools, dashboards, scripts, systems that exist because something bothered me enough to fix it myself.

NeonAIX fits right into that category.

It didn’t start as a big plan. It started because I was tired of juggling multiple AI tools, all of which were almost useful. One did this well, another did that well, and none of them worked together in a way that didn’t interrupt my train of thought every five minutes.

So instead of being productive, I did the reasonable thing and decided to build my own.

The Moment You Realize AI Isn’t Magic
Once you start building anything AI-related, the illusion fades fast.

At first it feels impressive. Then you realize it’s just very confident about things, whether they’re correct or completely made up. That’s when you learn about context limits, memory, retrieval, and why the same question can get a great answer one time and absolute nonsense the next.

AI turns out to be less like a genius and more like a very fast intern with excellent grammar.

Good results don’t come from clever prompts. They come from structure, guardrails, and deciding what the system should and should not be allowed to know.

“Learning” Sounds Cool Until You Have to Manage It
Everyone loves the idea of AI that learns.

Then you try to build one.

Learning means deciding what to store, what to ignore, what to verify, and what to throw away. If you don’t do that, your system slowly turns into a confident mess that remembers everything except the things that matter.

This felt very familiar. It’s the same problem you run into with logs, metrics, security alerts, and data pipelines. Too much noise, not enough signal.

Turns out AI doesn’t fix that problem. It just inherits it.

Limits, Everywhere
NeonAIX also introduced me to a long list of limits. Hardware limits. Model limits. Time limits. Budget limits. Patience limits.

Running AI locally is great until your GPU starts sounding like it’s questioning its life choices. Running it in the cloud is great until you do the math.

Every setup is a compromise. Faster usually means more expensive. Cheaper usually means slower. There is no magical configuration where everything works perfectly, and nothing breaks.

If someone tells you they’ve found that setup, they’re either lying or they haven’t used it long enough yet.

What NeonAIX Is Actually Doing
NeonAIX is not polished. It’s not finished. And it’s definitely not ready for anyone who expects things to “just work.”

What it is doing is teaching me how these systems are actually built. Not the surface-level stuff, but the decisions underneath. The tradeoffs you only see once something breaks and you have to figure out why.

That alone makes the project worth it.

I still don’t know what NeonAIX will end up being. A public tool, a personal system, or something else entirely. But I do know that building it has made AI feel a lot less mysterious and a lot more manageable.

Which is probably the healthiest outcome.

What’s Next (Probably More Breaking Things)
I’ll keep writing about this as I go. The wins, the mistakes, and the moments where everything works perfectly right up until it doesn’t.

Because even with AI involved, building things is still the same process it’s always been. Try something. Break it. Learn why. Repeat.

If you're into stuff like this, the original rant and more can be found on My Blog Page

Quantum Doomsday Delayed (Again): Why the Latest Panic Over Post-Quantum Cryptography Feels Familiar

Michael Roberts — Tue, 13 Jan 2026 05:48:10 +0000

This All Sounds Familiar
Seven years ago, I wrote my first master's thesis on the exact topic that's dominating security headlines today: the threat quantum computing poses to classical encryption. I spent months dissecting Shor's algorithm, modeling how a sufficiently powerful quantum system could reduce RSA and elliptic-curve cryptography to rubble. My conclusion at the time? The threat is real, but the timeline is long, and the migration will be an absolute nightmare.

Here we are in 2026, and the industry is once again sounding the alarm as if the quantum apocalypse has finally arrived. Spoiler: it hasn't.

The Threat That Refuses to Arrive on Schedule
The core issue remains unchanged. Today's public-key cryptography relies on mathematical problems that are hard for classical computers but potentially trivial for quantum ones. A cryptographically relevant quantum computer could, in theory, decrypt data that we currently consider secure for decades.

Sidebar: Shor's Algorithm – A Non-Technical Explanation

Picture your bank's encryption as a gigantic lock guarded by a single enormous number – one so large that multiplying two prime numbers together is easy, but figuring out what those two primes were (factoring) is practically impossible for normal computers. That impossibility is what keeps your data safe.

In 1994, mathematician Peter Shor came up with a recipe that only works on quantum computers. Instead of testing possibilities one by one like every classical computer has to, a quantum machine running Shor's algorithm can explore millions of possibilities simultaneously because of a quantum effect called superposition. It then uses another quantum trick – essentially a super-fast pattern recognition step – to spot the hidden rhythm in the results and spit out the two prime factors.

Translation: a task that would take today's best supercomputers longer than the age of the universe could, in theory, be done in hours or days on a sufficiently powerful quantum computer.

No magic, no science fiction – just physics taking a massive shortcut. That's why we're all scrambling to replace the locks before someone actually builds the key.

The twist everyone loves to invoke is "harvest now, decrypt later." Nation-states and sophisticated attackers are presumably vacuuming up encrypted traffic today, storing it in vast archives, waiting for the day they can run Shor's algorithm at scale. It's a chilling scenario, provided you enjoy dystopian speculation with your morning coffee.

2026: The Year of Mandatory Quantum Anxiety
NIST standardized the first post-quantum algorithms back in 2024 (ML-KEM, ML-DSA, SLH-DSA), and now governments are issuing roadmaps with actual deadlines. The G7 wants coordinated migration in financial systems. Various agencies are pushing for "quantum readiness" by 2035. Companies are rolling out quantum-safe VPNs, blockchain forks, and enterprise toolkits at a brisk pace.

Meanwhile, quantum hardware companies continue to announce breakthroughs in scalability and error correction, each one accompanied by the ritual phrase "inflection point." Yet no one has demonstrated a machine capable of running Shor's algorithm against real-world key sizes. Current estimates for that milestone still cluster in the 2030s, with generous error bars.

In other words, we're spending billions preparing for a threat that remains comfortably theoretical, while the passwords most people reuse from 2012 stay perfectly safe from quantum attack, if not from credential stuffing.

The Migration: A Gift That Keeps on Taking
Upgrading to post-quantum cryptography isn't like flipping a switch. It touches everything: TLS certificates, VPNs, secure messaging, code signing, blockchain consensus, embedded devices. Many systems are still dragging around cryptographic code from the early 2000s. The complexity makes the long-delayed IPv6 transition look like a weekend project.

Organizations are now forced to inventory decades of data, decide what needs long-term confidentiality, and begin hybrid deployments. It's expensive, error-prone, and offers exactly zero immediate benefit beyond checking a compliance box. One can't help but admire the dark comedy of it all: the security industry finally gets to sell the ultimate insurance policy against a risk that might materialize long after most of us have retired.

Final Verdict: Prepare, But Don't Panic
I'm not suggesting we ignore the problem. Post-quantum migration is necessary, and starting now is smarter than waiting. But the breathless annual declarations that "this time it's really coming" have become their own genre of performance art.

My old thesis warned that hype cycles would distract from the hard, boring work of incremental hardening. Seven years later, that prediction has held up better than most encryption schemes will against a future quantum adversary.

So yes, update your roadmaps. Inventory your sensitive data. Start testing hybrid certificates. Just don't expect the quantum crackers to show up next quarter. They've been fashionably late for three decades, and they're not about to ruin that perfect record now.

What do you think, overblown caution or prudent preparation? Drop a comment and let me know! I'll be here, calmly reusing a few passwords I probably shouldn't.

Find The Original Article and more on my blog site. Thanks for reading!

CES 2026: Why the "Smart Home" is Becoming a Cyber Security Dumpster Fire

Michael Roberts — Thu, 08 Jan 2026 03:13:38 +0000

Look, I am all for progress. I like fast internet and phones that don’t die in four hours as much as the next person. But after looking at the "innovation" coming out of CES 2026 this week, I have to ask: Has the tech industry collectively lost its mind?

This blog entry is going to be a little more of a rant than usual. I'm just in one of those moods. You have been warned.

It feels like we have moved past solving actual human problems and entered a phase of pure, unadulterated absurdity. We aren’t inventing the future anymore; we are just gluing Wi-Fi chips to random household objects and hoping some venture capitalist or bored consumer falls for it.

Hearing Music Through Your Teeth?

Take the Lollipop Star. This is a real product that people spent real money to develop. It is a nine dollar lollipop that uses bone conduction to play music inside your skull while you eat it.

Who asked for this? Was there a focus group of people saying, "I love sugar, but I really wish I could hear a true crime podcast vibrating through my molars at the same time"? It is the kind of thing you’d expect to see in a dystopian movie about the collapse of society, yet here it is, available in strawberry and blue raspberry.

Your Bedding Is Judging You

Then we have the AI-powered pillow. This thing is designed to detect your snoring and gently nudge you until you shift positions. On paper, sure, save the marriage. In reality, it is a five hundred dollar bag of foam that spends the entire night judging your respiratory system.

It even generates a weekly "Sleep Efficiency Report." I do not know about you, but the last thing I want on a Monday morning is a passive-aggressive email from my bedding telling me I failed at being unconscious.

Chainsaws with Espresso

The absolute peak of the madness, though, is the vibrating chef's knife. It supposedly uses haptic feedback to tell you if you are slicing at the wrong angle. Think about that. We took a sharp, dangerous blade and decided the best way to make it "smart" was to add unpredictable motorized shaking. It is like trying to improve a chainsaw by giving it a shot of espresso and a bad attitude.

The Cyber Nightmare of Smart Spoons

Since I usually talk about security here, I can't help but look at the fine print. Every single one of these gadgets requires an account. Every one of them wants to live on your home network and sync to the cloud. We are building a world where your kitchen utensils have more permissions than your actual employees.

I can already see the future headlines. Your smart spoon gets conscripted into a botnet to help a teenager in Latvia D-DoS a government agency. Or better yet, your smart chair locks you into a rigid, upright position because you forgot to pay your nine dollar monthly "Spine Plus" subscription. It isn't just annoying; it is a massive attack surface disguised as convenience.

The Subscription for Your Spine

It feels like we have reached a point of "Solutionism" where companies are inventing complex, hackable answers to questions nobody ever asked. We used to look at these shows for the next big leap in processing power or a revolutionary display. Now, we just watch startups spend millions of dollars trying to reinvent the concept of a rock.

My advice? If it needs a firmware update to help you eat, sleep, or cut a carrot, you probably don't need it. I am sticking with my manual toothbrush. It doesn't have an API, it doesn't track my data, and it has never once asked me to agree to a new set of Terms and Conditions just to clean my teeth.

Are you ready to let a piece of candy play Spotify in your jaw, or have we finally hit the limit of what we are willing to plug in?

Want more silly rants like this? Here you go:
https://michaelroberts.me/blog

I’ve Been Doing This for 25 Years and I Still Google Everything

Michael Roberts — Sat, 27 Dec 2025 01:33:59 +0000

Let's get this out of the way up front:

I’ve been working in IT for about 25 years, and I still Google things all the time.

Not in a “haha look at me being relatable” way. I mean constantly. Daily. Multiple times a day. Sometimes before I’ve even finished reading the error message because my brain already knows how this is going to go.

If that shocks you, you probably still think senior people just know stuff.

They don’t.

That thing people think happens eventually

There’s this weird idea that at some point, experience turns into permanent knowledge. Like one day you cross some invisible line and suddenly every command, port number, config option, and obscure error code just lives in your head forever.

That never happens.

What actually happens is you recognize the problem faster, you vaguely remember fixing something like it before, and you think, “I know this exists somewhere.” And then you open a browser.

Again.

What experience actually changes

Experience doesn’t stop you from looking things up. It just changes what you look up and how panicked you are while doing it.

Early on, you’re Googling things like “what is DNS” and “why does this not work.” Later, you’re Googling extremely specific phrases at 2am that only make sense to three other people on the planet.

Same process. Higher stakes.

Why Googling got such a bad reputation

Somehow Googling got treated like cheating.

As if you’re supposed to memorize the entire internet once you’ve been around long enough. No one expects a mechanic to remember every torque spec. No one expects a doctor to recall every interaction off the top of their head. But in tech, there’s this unspoken pressure to act like you’re supposed to.

The people who say they don’t Google anymore are either lying, forgetting things, or absolutely terrifying.

Impostor syndrome just changes its name

Impostor syndrome doesn’t really go away either. It just gets better PR.

At some point you stop saying “I have no idea what I’m doing” and start saying “huh, that’s interesting” instead. Same feeling. Just sounds more confident.

You still second-guess yourself. You still wonder if everyone else secretly knows more than you. You just have enough scars now to know you’ll probably figure it out again.

Or roll it back.

Or Google harder.

This is still how it works

After 25 years, I still copy and paste commands. I still double-check syntax I’ve typed a hundred times. I still search for things I know I’ve solved before because my brain refuses to keep them forever.

And honestly, that’s fine.

If you’re Googling things constantly, you’re not failing. You’re doing the job. That never stops. The only difference is you get better at filtering out bad answers and knowing which results are going to waste your time.

If you ever reach a point where you think you don’t need to Google anymore, that’s when I’d start to worry.

If you like this kind of writing, I keep more of it on my personal blog at michaelroberts.me.

...Yes, I googled something while writing this

Why I Still Build Things No One Will Ever Use

Michael Roberts — Sat, 20 Dec 2025 08:38:58 +0000

I’ve built a lot of things that never shipped.

Side projects. Scripts. Little tools. Half-finished ideas that lived entirely on my laptop and quietly disappeared when I got distracted by something else.

If success is measured by launches, users, or money, then yeah — most of this was a waste of time.

Which is inconvenient, because I keep doing it anyway.

Somewhere along the way, everything stopped needing a reason

Early on, every project had to justify itself.

Learn this so it helps my career.
Build that so I can talk about it later.
Ship something so it looks like progress.

That works for a while. Then it just gets tiring.

These days, a lot of what I build exists because I’m curious, or annoyed, or trying to scratch an itch that only I seem to have. Sometimes I just want to see if an idea will fall apart, and usually it does. That’s fine.

No roadmap. No planning. Definitely no tickets. Just me, a terminal, and a questionable decision.

The stuff that actually taught me something never shipped

Most of the things I rely on professionally didn’t come from neat tutorials or carefully planned projects.

They came from breaking my own code, rewriting the same thing multiple times, and realizing an idea was bad only after I’d already sunk time into it. I’ve chased bugs that didn’t matter and performance issues no one would ever notice, and somehow those are the moments that stuck.

None of those projects went anywhere.
The lessons did.

They show up later, usually when something breaks in a real environment and my brain goes, “oh… I’ve made this mistake before.”

Shipping matters, just not always

Yes, real-world experience matters. Shipping things matters.

But not every project needs to turn into something useful, profitable, or impressive. Some things exist just to keep your brain sharp, remind you why you liked building things in the first place, or keep you from burning out entirely.

If every line of code has to justify its existence, eventually everything starts feeling like work.

Why I’m posting this here

This is also a stress outlet for me. Even if no one reads a single word, it helps me to write it out anyway.

If you’ve ever built something just to see if you could, you’re probably not alone.

If you want more of this (fair warning)

I write longer, messier thoughts like this on my personal blog.
No lessons promised. No guarantees. Just tech, side projects, and the occasional bad idea.

If that sounds appealing, it lives here:
https://michaelroberts.me/blog