Check the Power Supply First
A few weeks ago one of the small computers that runs my background work started handing back garbage. Not every time. Just sometimes, and mostly on big files. I would copy something off it, and the copy would not match the original.
My first instinct was the interesting explanation. A bug in my code. A bad update. Something clever had gone wrong in something clever I built.
It was the power supply.
The little machine was not getting quite enough power, and when it ran short, it quietly did a worse job reading its own files. It even logged a warning about it. I had just never looked, because a power warning is boring and I was busy being clever.
The boring layer holds everything up
Every setup I have ever built has the same shape. A pile of interesting stuff on top, the part I like working on, and underneath it a thin layer of plain things nobody thinks about. Power. Cables. Backups. The password that expires once a year. The card on file that runs out in March.
The interesting stuff gets all the attention because that is where the fun is. The plain layer gets none, right up until it fails. And when it fails, it does not fail politely. It makes everything above it look broken in strange ways, so you go looking for a strange cause.
That is the trap. A weak foundation does not announce itself. It shows up as a symptom somewhere else, usually in the part you care about most, so you start debugging the wrong thing.
Check the dumb stuff first
I have a rule now, and it is not complicated. When something acts weird, check the dumbest possible cause before the smartest one.
Is it plugged in. Is it getting enough power. Is the disk full. Did a login expire. Did a bill fail. Is the cable the cheap one from the junk drawer.
Nine times out of ten that list finds nothing, and you have lost two minutes. The tenth time it saves you a whole evening of chasing a ghost through code that was never the problem.
This works outside of technology too. When a business that used to run fine starts slipping, the cause is rarely the new strategy. It is usually something plain that quietly stopped happening. Invoices that stopped going out on time. A follow up nobody owns anymore. A supplier who changed one small term. The fancy explanation is more fun to think about, which is exactly why it gets checked first and the real cause gets checked last.
Spend on the foundation on purpose
The fix for the power problem costs less than a tank of gas. That is the part that stings. I had put hours into the software running on that machine and about thirty seconds into choosing the thing that feeds it electricity.
I wrote before about the real cost of free tools, and this is the hardware version of the same idea. The cheap part you never think about ends up being the most expensive part you own, because it takes everything above it down with it.
So the rule I am holding myself to now: spend a little extra on the parts that sit at the bottom. The power supply. The backup drive. The second copy of anything I cannot replace. None of it is exciting, and none of it ever will be. It is the stuff that lets the exciting stuff keep working.
What I am doing differently
Before I build something new, I write down the plain layer before I start on the fun part. What does this need to stay on. What does it depend on that could quietly expire. Who or what notices if that dependency goes away.
It takes five minutes. It is the least interesting five minutes of the whole project. It is also the part that decides whether the project is still running six months from now, which connects to something I keep relearning: one finished thing beats ten rough ones, and nothing counts as finished if it falls over the first time the power flickers.
Check the power supply first. It is almost never the answer. When it is, it is the whole answer.
