Combat Medic → Software Engineer — An unconventional path
Context: Former U.S. Army combat medic (82nd Airborne) now studying web development (Full Sail B.S., graduation Oct 2025) and interning in AWS Cloud Support. No paid SWE role yet.
AI assist: ChatGPT helped me organise interview stories into this outline; every anecdote comes from my journals and mentor feedback.
Status: Reflection, not a victory lap. I’m documenting the throughline so hiring managers know what’s real.
Reality snapshot
- Military experience = 3.5 years triaging casualties, coordinating medevacs, and running aid stations.
- Civilian roles (case management, security, construction, animal rescue) reinforced empathy, logistics, and practical problem solving.
- Today’s work = student projects (Car-Match, Triangle Shader Lab, CheeseMath), AWS internship labs, and an honesty-first portfolio.
Transferable muscles
| Past role | What I actually did | How it shows up now |
|---|---|---|
| Combat medic | Stabilized multiple patients, prioritized severity, called in specialists, documented everything | Incident triage mindset: reproduce bugs fast, label severity, route owners, capture postmortem notes (Car-Match runbooks, AWS lab retros) |
| Case manager | Tracked complex cases, aligned families/providers, maintained daily status reports | Stakeholder comms: weekly updates to professors, internship mentors, and project collaborators |
| Construction | Worked from blueprints, adapted when materials/weather shifted, led small crews | Product agility: roadmap Car-Match features, adjust scope when Render cold starts or Atlas limits pop up |
| Animal rescue | Stayed calm with limited gear, made humane but tough calls, logged each event | Pragmatic delivery: cut scope when exhaustion rises, focus on user impact (accessibility, reliability) over “shiny” features |
How it translates to engineering work
Triage before heroics
When Car-Match’s backend sleeps on Render, I stabilize first (wake instance, log downtime on the site) before exploring cron jobs or paid tiers. Same with AWS labs: collect signals → narrow blast radius → document the fix.
Story-first communication
Patient charts demanded “Situation → Background → Assessment → Recommendation.” I use the same format in pull requests, runbooks, and status updates so teammates can act quickly.
Planning with contingencies
Military logistics = backups for everything. In software that means fallback content, cached API responses, or documented manual overrides. My READMEs call out cold starts, feature flags, and “if this breaks, do that” steps.
Empathy under pressure
Calm tone during outages, demos, or tough feedback sessions matters. I learned that rescuing animals and sustaining morale on long missions. Now I use it to facilitate study groups, run peer reviews, and keep honesty logs even when the results aren’t flattering.
Proof points
- Runbooks & retros:
/docs/runbooksin most repos + AWS internship notes show the triage/comms habit in action. - Honesty updates:
honesty.md+honestplan.mddocument every copy change and limitation on my portfolio—transparency born from medic-level accountability. - Community work: Tech Talk Club coordination + CIRIS documentation contributions rely on the same skills as managing aid-station crews.
Case studies that show the translation
- Gatsby nav bar meltdown: Treated it like a mass-casualty event—identify symptoms, sort by severity (layout first, then interactions), isolate root cause (bad DOM structure), rebuild, write a retro. Result: stable nav and a blog post that doubles as evidence.
- Service worker hostage situation: Cached site wouldn’t update. I gathered signals (curl, incognito, DevTools), unregistered the rogue worker, wrote a step-by-step guide so others could avoid it. Same playbook as clearing a blocked airway: assess, clear, re-verify.
- AWS internship lab drills: Built dashboards and alarm playbooks. The habit of rehearsing medevac steps translated into runbook dry-runs—walkthroughs before the real alarm hits.
Interview stories (STAR-ready)
- When time and resources were limited: On a field exercise with scarce supplies, I prioritized patients and communicated trade-offs. In tech, I mirrored this when Render cold starts hit Car-Match: woke the instance, posted downtime notes, deferred non-critical features, and documented a fallback plan.
- When a tool failed mid-mission: During an animal rescue, our radio died; we pivoted to hand signals and written notes. Recently, when GitHub Actions secrets broke, I switched to manual deploys, updated the README with steps, and opened an issue with repro details instead of panicking.
- When I had to say “I don’t know” fast: In the Army, guessing could cost lives. Now, in study groups or project reviews, I flag uncertainty immediately and propose next steps (trace logs, add tests, pull in a mentor). It builds trust and keeps momentum.
Gaps, missteps, and how I’m fixing them
- Over-indexing on hustle: Early on, I tried to outwork gaps instead of narrowing scope. Now I cap weekly hours and define a “minimal viable proof” for every goal.
- Too many tools, not enough depth: I bounced between stacks. The fix: pick a focused tech trio per quarter (e.g., React + AWS basics + testing) and log every deviation.
- Underestimating math/CS weight: I skipped fundamentals until interviews exposed it. I’m adding weekly data-structure reps and pairing them with small feature rewrites to reinforce muscle memory.
- Letting AI over-speak: Copilot sometimes invents patterns. I started keeping a “hallucination log” and require source links before merging AI-suggested changes.
How I present this on a resume or portfolio
- Lead with the throughline: triage → comms → delivery under constraints.
- Pair every bullet with proof: link to runbooks, postmortems, or commit diffs.
- Keep titles honest: “Student developer” and “Intern” instead of inflating.
- Add a “service mindset” section with concrete behaviors (status updates, checklists, fallback plans).
Playbook for other veterans switching to tech
- Translate missions to incidents: symptoms, severity, owners, timelines.
- Practice calm communication: Situation → Background → Assessment → Recommendation works as well in Slack as it did in a field report.
- Rehearse under load: runbook dry-runs, chaos drills on side projects, and mock interviews.
- Guard your energy: apply the same discipline to rest and recovery as you did to PT.
Open questions I’m still working through
- How to get real on-call experience without over-selling myself.
- Best path to earn trust on a team quickly while being transparent about student-level gaps.
- Which senior mentors to shadow for “calm under pressure” in production environments.
- How to measure whether my “service mindset” actually reduces incident friction on a team.
Where I still need mentorship
- Deep CS topics (algorithms, distributed systems).
- Running real on-call rotations with customers on the line.
- Leading cross-functional engineering projects (beyond student teams).
- Translating empathy into scalable processes (incident response, accessibility reviews, documentation ops).
Takeaways for other career-changers
- Catalog your previous playbooks. You probably already know how to triage, document, and communicate—just reframe it.
- Stay honest about gaps. I say “student-level” every chance I get so expectations match reality.
- Keep serving. Whether it’s open-source docs, study groups, or honest portfolios, the service mindset still applies.