April 14, 2026 · IT & Operations

What Hospital IT Taught Me About Shipping Software

By Mark Thomas Firestone

Before Bangkok, before Bitcoin.com, before any of the web work that fills my calendar today, I spent years as the head lead technician for hospitals in Bakersfield, California. That work shaped how I think about software more than anything else on my résumé.

Uptime is a moral concern

In a hospital, "the server's down for a minute" can translate into nurses unable to pull up a medication record. You learn very quickly that uptime is not a vanity metric. The habit follows me into web development: I instinctively design for failure modes I'd be embarrassed to debug at 3 a.m.

Documentation is a love letter to your future self

Healthcare IT runs on documentation. Runbooks, change logs, vendor escalation paths. When I switched into full-time development, I kept the habit. Tests are documentation. README files are documentation. Good commit messages are documentation. Skip them and someone — eventually you — will pay for it.

Workarounds are technical debt with a uniform

A quick fix on a Tuesday afternoon in a hospital can become next quarter's compliance finding. I push for root-cause fixes because I've watched what happens when you don't. The web is more forgiving than a hospital, but the dynamic is identical.

Security is not a feature, it's a posture

HIPAA didn't teach me cybersecurity techniques — it taught me cybersecurity discipline. Patching cadence, access reviews, audit logging, least privilege. The same posture protects a Thai startup's customers today.

Calm beats clever

The best hospital IT people I worked with were not the most brilliant — they were the calmest. Steady, methodical, clear-headed under pressure. I try to bring that energy to every project. Brilliance is overrated; calm is underrated.