From Athletic Trainer to Techie: How Healthcare Shaped My Approach to Tech

In 2015, I watched the coding wave pass me by. I was in college, I saw people learning to build things, and I told myself it was too hard not for me. So I stayed in my lane.

My lane was athletic training. And honestly? It was a great lane. Over the next decade I worked sidelines in the NFL, MLS, NCAA Division I, and more. I got good at the craft. Really good.

But I kept watching. And I kept seeing people regardless of their major, their background, their "lane" adding tech to their toolbox and quietly gaining an edge. A data analyst here. A no-code builder there. People solving their own problems instead of waiting for someone else's app to do it for them.

I didn't want to be the person who ignored the internet. Or like our parents fumbling through their first iPhone. Missing a wave once is a lesson. Missing two is a choice.

The "Funemployment" Realization

During a recent break between jobs, I had some decompression time I didn't expect. No roster to manage, no sideline to staff. Just time to think.

What I realized: I had spent ten years mastering one very specific craft. And I was proud of that. But I wanted to be more broadly useful to myself, to the people around me, to problems I hadn't encountered yet.

What pushed me over the edge wasn't ambition. It was frustration. Subscription prices going up. Owning less and less of the tools I depend on. Needing someone else's app for every small task. I was tired of it. I wanted to build my own stuff.

The Skills Were Already There I Just Didn't Know It

Here's the thing nobody tells you when you come from a non-technical background: the thinking is already there.

In athletic training, you don't just treat the symptom. A player limps off the field you don't tape the ankle and send them back out. You assess the mechanism of injury, rule out what it isn't, and trace back to the root cause.

Debugging code works exactly the same way. The error message is the symptom. The real work is reading the stack trace, isolating the failing component, and understanding why not just what broke. Both fields punish people who jump to quick fixes.

I was also already working with data before "data-driven" was a buzzword. Tracking GPS loads, monitoring heart rate variability, analyzing performance trends across an entire roster. That work eventually led to my first real project: a dashboard that pulled all of that data into one place. The domain knowledge came from the field. The execution came from finally learning to build.

And then there's communication something healthcare forces you to get good at fast. Explaining a complex injury to a coach, a return-to-play timeline to an athlete, a medical recommendation to a worried parent. Each conversation requires translating technical information for a completely different audience. Turns out that skill is just as critical in a product meeting or a code review.

What I'm Actually Doing Now

I'm not trying to build the next billion-dollar Silicon Valley unicorn. That's not the goal.

The goal is to become digitally bespoke to stop depending on pre-built "sets" and start snapping my own blocks together. AI is basically a giant bucket of digital Legos, and I'm done waiting for someone else to hand me the instruction manual.

This site is where I document that process. The builds, the breaks, the "oops, that didn't work" moments, and the slow progress toward not needing someone else's subscription for every small thing I want to do.

If you're coming from a non-technical background and thinking about making a similar move your experience isn't a liability. The way you think about problems, communicate, and care about getting things right? That stuff matters. You're not starting from zero. You're just learning a new set of blocks.

Welcome to the building site. Hard hats recommended. 👷‍♂️