From Combat Medic to Code: How Military Discipline Shapes My Development

I spent five years as a combat medic in the U.S. Army, stationed at Fort Hood and Fort Bragg. I led a team of three medics and two combat lifesavers. I delivered emergency care in situations where hesitation cost lives and mistakes weren't optional.

Twenty-five years later, I write code for a living. And I use what the Army taught me every single day.

Protocols Are Tests

In the Army, we had protocols for everything. TCCC (Tactical Combat Casualty Care) told you exactly what to do when someone was bleeding: massive hemorrhage control, airway, respiration, circulation, hypothermia prevention. In that order. Every time.

You didn't improvise. You didn't skip steps because you thought you knew better. You followed the protocol because the protocol was designed by people who'd seen every way things could go wrong.

In software, automated tests serve the same purpose. They're protocols that verify your code does what it should, in the order it should, every time.

When I write a test before I write a feature, I'm doing the same thing we did in medical training: defining what "right" looks like before the pressure is on. Then when I'm deep in implementation and things get complicated, the tests keep me on track.

I run the full test suite before every deployment. Not because I think something is broken, but because the Army taught me that confidence comes from verification, not assumption.

Equipment Checks Are CI/CD

Every morning in the Army, you check your equipment. Medical kit: packed, organized, nothing expired. Weapon: clean, functional, properly zeroed. Vehicle: fuel, oil, tires, comms.

You don't check your equipment when you need it. By then it's too late. You check it every day so that when you need it, you know it works.

CI/CD pipelines are the same concept. Every commit triggers a build, runs the tests, and verifies the deployment configuration. I don't wait until a customer reports a bug to find out the checkout is broken. The pipeline catches it before the code reaches production.

My CI pipeline runs:

• TypeScript compilation (catches type errors)
• ESLint (catches code quality issues)
• Playwright E2E tests (catches broken user flows)
• Accessibility tests (catches WCAG violations)

If any of those fail, the deployment stops. Just like in the Army: you don't roll out with a broken radio.

Staying Calm Is Debugging

The first time you see real trauma, your brain wants to panic. Your heart rate spikes. Your hands shake. Everything in your body screams "run."

Medic training doesn't eliminate that response. It teaches you to work through it. Acknowledge the stress, set it aside, and focus on the next step. Massive hemorrhage: apply tourniquet. Airway: check. Move to the next thing.

Debugging a production incident at midnight feels like a smaller version of the same thing. The site is down. Customers are affected. Slack is blowing up. Your brain wants to panic.

The military response: assess the situation, identify the most critical issue, fix that first, then move to the next one.

I once spent four hours debugging a checkout failure that was costing real revenue. At hour three, I wanted to start randomly changing things to see if something worked. That's the developer equivalent of panic — throwing solutions at a wall instead of diagnosing the problem.

Instead, I did what medic training taught me: slow down, check the basics (logs, database state, API responses), isolate the failure point, and fix it methodically. The bug was a race condition in the cart synchronization. Random changes would have never found it.

After Action Reviews Are Retros

After every significant event in the military, you do an After Action Review (AAR). What happened? What was supposed to happen? What went right? What went wrong? What do we do differently next time?

No blame. No defensiveness. Just honest analysis.

I do the same thing after every significant bug or incident. When the request deduplication system failed to catch a duplicate payment, I didn't just fix the bug. I asked: Why did the test suite miss this? What monitoring would have caught it earlier? How do I prevent this category of bug in the future?

The fix was 10 lines of code. The lessons from the AAR changed how I write tests for every feature since.

Team Leadership Is Code Reviews

In the Army, I was responsible for my team's performance. When a new medic joined, I didn't hand them the manual and say "figure it out." I showed them how we did things, explained why, and checked their work until I was confident they could work independently.

Code reviews work the same way. When I review code (my own or someone else's), I'm looking for the same things a team leader checks:

• Does this follow our established protocols (coding standards)?
• Will this work under stress (edge cases, error handling)?
• Is this maintainable when the author isn't around?
• Could a new team member understand this?

I write code with the assumption that someone else will maintain it. Just like I organized medical kits with the assumption that someone else might need to find a tourniquet in the dark.

The Uncomfortable Truth

I'll be honest about something: transitioning from the military to civilian work was hard. The structure, the clear chain of command, the unambiguous mission — none of that exists in the civilian world.

Software development can feel chaotic. Requirements change. Priorities shift. Nobody tells you exactly what to build or how to build it.

But the core skills transfer: discipline to do the boring work (tests, documentation, maintenance), calmness when things break, attention to detail when it matters, and the understanding that preparation — not talent — is what separates reliable performance from luck.

I didn't plan to become a developer when I left the Army. But the Army gave me the foundation that makes me the developer I am today. You can read more on my resume or learn more about me.

If you're a veteran considering tech: your experience is an asset, not a gap. The discipline you learned under real pressure is exactly what software teams need. Don't let anyone tell you otherwise.