
What you actually need to build software (it isn't code)
A physical therapist’s day starts with the body and ends with the body.
You loosen stiff shoulders. You coax a paralyzed leg to fire, the same motion forty times over. You stand close so a patient doesn’t fall. By the end of the day your wrists ache and your lower back is tight. That was my work for years. Your body is the tool, and you grind a little of it away every day.
And then the day still wasn’t over.
After every patient came the paperwork. What treatment was done, how the patient was doing, which day of admission they were on. You wrote it on a chart, then copied it onto another form, and at the end of the month someone gathered all that paper and counted the numbers. By hand.
People who were already wrung out from a full day of patients sat down at a desk in the evening and got wrung out one more time.
The thing I couldn’t let go of
That always bothered me.
Why copy the same thing two or three times? Why rebuild this same monthly report from scratch, every single month? Does a human really have to do this?
Most people shrugged: that’s just how it is. I couldn’t do that. Once I noticed an inefficiency, it wouldn’t leave my head. I’d be eating dinner, or driving home, and still turning over how do I make that go away. Call it a personality trait. Some days it felt more like a condition.
Looking back, that one restless feeling was the whole thing. Not skill. Not knowledge. Just the inability to see something wasteful and leave it alone.
A calculation that kept pushing me
So I kept trying to change things.
It didn’t always work. Often it got more annoying before it got better, and sometimes it just got tangled. But I never felt like I’d lost anything.
If it worked, I got the time back. If it failed, I learned this way doesn’t work — so next time I wouldn’t go down that road.
Succeed and you gain efficiency. Fail and you gain experience. Either way you come out ahead. That simple math is what kept shoving me toward the next attempt. It’s also the single most useful mindset I can hand you: a failed experiment is not a loss. It’s a paid lesson.
It was never really about me
When I took over as head of the therapy unit, the feeling outgrew my own desk.
Therapists are already physically spent. I didn’t want to pile pointless work on top of that. And it wasn’t just “it’s nice when staff have it easier.”
When people are freed from busywork, they spend that energy on patients. More focus on treatment means patients get better. Remove one inefficiency and, somehow, it travels all the way down to the person in the bed.
That loop is what I was actually after. Take the work that humans do like machines, and hand that energy back to the things only humans can do. That’s the grand version. The plain version: I wanted everyone to get ground down a little less.
There was just one problem
I couldn’t do any of it.
I didn’t even know what code was. Code was further away than a foreign language. Software was something other people made — smart people at some distant company who built it and sold it. People like me didn’t make software. All I had was that restless feeling and a few questions that wouldn’t leave me alone.
If you’re waiting until you “know enough” to start, I want to be honest with you: I started with less than nothing. No course, no certificate, not even the vocabulary. What I had was a problem I couldn’t stop thinking about.
It turns out that’s the part you can’t outsource. The coding, the tools, the syntax — all of that can be learned, borrowed, or handed to an AI. But caring enough about a specific broken thing to keep poking at it? That has to be yours.
So before any tutorial, the real question isn’t can I code. It’s this:
What’s the one repetitive thing that wastes your time every week — the one you can’t stop noticing?
Start there. That’s where I started, standing in front of a pile of documents that six different therapy rooms each filled out their own way. But that’s the next story.