What Industrial Machinery Taught Me About Debugging Software

I don't work in a software company. I work with air compressors—the kind that sit in factories, run for 20,000 hours, and fail at 3 a.m. on a Sunday.
But over the last two years, I've been building and maintaining my own website for the industrial business. I'm not a trained developer. I'm what people now call a "vibe coder"—someone who uses AI tools, documentation, and a lot of trial and error to ship something that works.
What surprised me is how much the mindset of industrial maintenance overlaps with debugging software. Here are four lessons that transferred directly.

1. The fault is rarely where the alarm is In a compressor, a high-temperature alarm might be triggered by a clogged oil filter, a failing fan, or a sensor that's simply drifted. The alarm is a symptom, not the cause. In software, a 500 error on a form submission might be a missing validation rule, a database timeout, or a permissions issue on an API key. The stack trace points to the line that broke, not the line that caused it. The habit I carried over: before touching code, ask what changed. In maintenance, we check the logbook. In development, I check git log and recent deploys. Nine times out of ten, the answer is in the last three changes.
2. Preventive maintenance beats emergency repair A factory that waits for a compressor to seize up pays ten times more than one that changes the oil on schedule. Software is the same. A dependency update, a backup test, or a 10-minute check of error logs every Monday saves a weekend of firefighting. I now run a simple weekly checklist: Check the error log for new patterns (not just count).
 Verify the backup actually restores.
 Update one dependency, not all of them at once.
 It's boring. It works.
3. Documentation is not for "later"—it's for you, next month In industrial settings, every machine has a manual, and every site has a logbook. When a technician opens a panel, they expect to find a wiring diagram. If it's missing, the job takes three times longer. When I started, I didn't document anything. Three months later, I couldn't remember why a certain redirect rule existed. Now every non-obvious piece of code gets a one-line comment explaining why, not what. The "what" is already in the code. The "why" disappears from memory in weeks.
4. The best tool is the one you can fix yourself Industrial engineers are pragmatic. If a generic part works, they use it. If it fails, they need to be able to replace it without calling the manufacturer. In software, this translates to: prefer boring, well-documented technology over clever, fragile technology. I use a static site generator and plain HTML/CSS where possible. When something breaks, I can read the source, search the docs, and fix it. That's worth more to me than a framework that saves an hour of setup but costs a day of debugging when it changes. What I'm still learning I'm not going to pretend I'm a senior developer. I still struggle with build pipelines, I still copy-paste from Stack Overflow, and I still break things in production. But the industrial mindset—observe, isolate, fix the cause, document, prevent—has made the learning curve gentler. If you're a developer, the next time you debug something, try asking: "If this were a machine on a factory floor, what would the maintenance technician check first?" You might be surprised how often the answer is the same.

Kourosh Behrouzi works in industrial machinery and writes about building practical tools for the industrial sector. He maintains a resource site about air compressors at https://jahancompressor.com/