I’m currently relearning the Core Three — HTML, CSS, and JavaScript — as I work toward becoming a full-stack JavaScript developer.
Before I came back to learning software, I spent 22 years working industrial turnarounds.
One lesson from that world has followed me into software engineering:
Never trust a single point of failure.
In industrial maintenance, there’s a safety practice called double block-and-bleed.
Instead of trusting one isolation valve, you use two independent valves with a bleed point between them. If one valve leaks, you know immediately. The entire system assumes individual components can fail.
Safety doesn’t come from perfect parts.
It comes from independent layers of protection.
That idea completely changed how I think about CI pipelines.
When I first started relearning web development, my mindset was simple:
Run Lighthouse.
Everything green?
Great.
100 across the board locally?
Even better.
Ship it.
Different results after deployment?
Uh-oh.
Now I see Lighthouse as one checkpoint — not the finish line.
A fast website can still have accessibility issues.
An accessible site can still have broken metadata.
Good SEO won’t catch rendering bugs.
Passing unit tests won’t tell you if the generated HTML is malformed.
Every tool has blind spots.
No single tool should get the final vote.
So instead of asking:
“Did my tests pass?”
I ask:
“What kinds of failures could still slip through?”
That question naturally leads to layered validation.
- Formatting
- Linting
- Type checking
- Accessibility checks
- Performance audits
- HTML validation
- SEO analysis
- Manual review
None of these tools is perfect.
Together, they’re much stronger than any one of them alone.
The more I learn about software, the more I find myself applying lessons from heavy industry.
Different environment.
Different risks.
The same engineering mindset.
Assume components will fail.
Design systems that fail safely.
That’s becoming the philosophy behind every test matrix and CI pipeline I’m designing.
What’s one engineering principle from outside software that’s changed the way you write code?
Top comments (2)
How do you think the refinery analogy applies to handling pipeline failures, and do you have any favorite strategies for debugging CI issues? I'd love to swap ideas on this.
Great question. Full disclosure: I’m definitely not a CI expert. Before my current project, I honestly didn’t know much about CI beyond the basics. I ended up learning because the project reached a point where it became necessary, and that’s when the refinery analogy really clicked for me.
The comparison actually gets stronger when something fails.
In a refinery, you don’t just restart a unit and hope for the best. You gather evidence: alarms, process data, upstream/downstream effects, and the last change that was made. That’s how I’ve started looking at CI failures too. My first questions are:
One lesson I carried over from industrial work is that the first alarm isn’t always the root cause. It’s often just the first instrument to detect a problem that started somewhere upstream. CI pipelines seem to behave the same way.
So I’m still learning, but I’ve found that treating CI like an engineering investigation instead of just a pass/fail gate has been a really useful mindset.
I’d be interested to hear your approach too. What strategies have worked best for you when you’re tracking down a stubborn CI failure?