When people learn I was a wildland firefighter before becoming a software engineer, they usually assume these are two completely unrelated chapters of my life. They're not. The truth is, nearly everything I learned on the fireline directly applies to how I handle production incidents today.
The Selection Process Sets the Tone
Out of 60+ trainees who started the wildfire training program, only 11 of us made it through. The program was a week of 8-hour classroom days covering fire behavior, safety protocols, and suppression tactics, followed by field exercises — digging line, deploying hose, learning to read terrain and weather. If you weren't paying attention in class, you were out. Score below 80% on any quiz or test, you were out. The final day was a gauntlet: the pack test, field exercises, and practical evaluations back to back.
The 82% attrition rate wasn't just about physical fitness — it was about sustained focus, discipline, and composure under evaluation. Could you absorb dense material all day, then perform under pressure when it mattered?
Those same qualities determine who thrives during a production incident. The engineers who stay calm, recall the system architecture under stress, and communicate clearly — they're the ones you want on the call.
Size Up Before You Act
In firefighting, you never just charge at a fire. You size up the situation first: What's the fuel? What's the terrain? What's the weather doing? What direction is the fire moving, and how fast? Then you evaluate your options and their tradeoffs. A burnout operation might contain the fire quickly, but if the prescribed fire escapes, you've just spread your resources thinner fighting two fires instead of one. Every strategy has a risk profile, and choosing wrong makes things worse.
The subtle details matter most. A slight change in wind direction, a shift in humidity, the way smoke is behaving — these are easy to miss in the moment but dictate how the fire will act hours later. You learn to read the signs early or you're reacting too late.
Debugging production issues feels remarkably similar. The obvious error in the stack trace is rarely the root cause. It's the subtle clue buried in the logs — a null value that shouldn't be there, a code path that only triggers under specific conditions, a data format edge case that nobody accounted for. The UTF-8 corruption bug I fixed at Act-On affected 70-80% of customer accounts, but it wasn't surfacing as a UTF-8 error. You had to read the signs carefully to trace it back to the actual cause. In both cases, the skill isn't just seeing what's in front of you — it's reading the situation deeply enough to find the real problem before you waste time fighting the wrong fire.
Communication Is Non-Negotiable
On a wildfire, we communicated fire behavior constantly — with our crew, with other teams on the ground, and with air attack overhead. If you saw the fire change behavior, you called it out immediately. There was no “I'll mention it later.” Lives depended on information flowing fast and accurately.
In software, I've carried that same discipline. When I see something wrong in production — even if I'm not sure it's a real problem yet — I communicate it. I've seen too many incidents get worse because someone sat on information, thinking it wasn't important enough to share.
You Fight the Fire You Have, Not the One You Planned For
We trained for initial attack, direct attack, indirect attack, and burnout operations. But real fires don't follow your playbook. The wind shifts. The terrain funnels the fire somewhere unexpected. You adapt or you're in trouble.
Production incidents are the same. You can have runbooks and playbooks, but the real skill is adapting when the situation doesn't match what you expected. The best incident responders I've worked with share this trait with the best firefighters I worked with: they stay calm, reassess, and adjust.
Holding the Line
Building and holding fireline is unglamorous, exhausting work. You're digging, cutting, clearing — creating a boundary the fire can't cross. It's not heroic. It's discipline.
The engineering equivalent is the monitoring, alerting, and operational hygiene that prevents incidents in the first place. At Act-On, I established comprehensive monitoring and alerting across key services that catches issues in real-time. Before that work, problems could go undetected for up to a month. That's the engineering version of holding the line — it's not flashy, but it's what keeps the system standing.
The Transferable Truth
Firefighting taught me that high-pressure situations reward preparation, communication, and humility. You don't panic. You don't freelance. You trust your training, communicate clearly, and adapt when the situation changes.
Those principles have made me a better engineer every single day.