I learned to program at ten, the year my father died and my mother went back to school.
She had an advanced physics degree from Iran, but in the United States the credential did not carry weight, and she enrolled in a computer science undergraduate program to start over. Her English was still rough at the time. The textbooks were the hardest part. We sat at the kitchen table after school with a dictionary, and I worked through the chapters with her, paragraph by paragraph. She was the one earning the degree. I picked up the language of the textbooks along the way.
I was not interested in programming. I was a ten-year-old who did not want to spend his afternoons on undergraduate computer science. What happened instead, mostly through repetition, was that the structure of the chapters lodged itself somewhere. The algorithms had a shape that survived the labor of reading them. By the time we finished a chapter I had usually written something resembling what it described.
By high school I was running parallel-computing problems on a cluster at a national lab. The first big project, the one I won the NSF Supercomputer Challenge with, was a population genetics simulator that used a primitive neural network to model how selection pressure shaped allele frequencies across generations. I worked my way through the rest of high school and most of college doing IT, fixing whatever was on fire that day at whatever small business had me on call.
I tell that story for one reason. It is the only reason I can read a piece of clinical software and explain, in technical detail, exactly why it is bad.
Why medical software is the way it is
Most clinical software is bad because the people who build it and the people who use it almost never overlap. A health system rolls out a documentation tool designed by a vendor whose product team has, on average, zero hours of clinical work. The clinicians who will use it for the next decade have, on average, zero hours of software engineering. The handoff between those two groups is mediated by a procurement contract. The interface that emerges from that exchange is the interface we live with.
The result is a clinician at a workstation, at six in the evening, two hours after their last patient went home, clicking through dropdowns to satisfy a documentation requirement that nobody on the design team has ever satisfied themselves. A landmark 2016 study in the Annals of Internal Medicine found that for every hour of direct patient face time, physicians spent nearly two additional hours on electronic health records and desk work. None of that is software working as designed. All of it is software working exactly as designed, by people who were not in the room.
The standard explanation has been that clinical software is difficult to build because clinical workflows are complex. That is true. The unspoken second half is that clinical workflows are also legible. They are well documented, they have been studied for decades, and the people who actually do them are the most expensive workforce in the country to keep waiting. If a software team genuinely wanted to design for them, the information was there.
What is changing
The structural barrier between the people who use clinical software and the people who build it was, until recently, that building took years of dedicated technical training. Most clinicians spent those years on something else. AI development tools have collapsed that lift. A working physician sitting at the kitchen table after the kids are asleep can now ship a real clinical tool over a weekend. The slow training of an engineer is no longer the prerequisite. The clinical understanding is.
This is not a hypothesis. It is happening. A radiologist who reads three hundred chest CTs a week writes a triage assistant that respects how triage actually feels. An emergency physician prototypes a decision tool that fires only on the cases where it would have changed management. A pediatrician ships a discharge-summary generator that answers the five questions every parent actually asks. A pathologist publishes a fast image-viewer optimized for the way they read slides. These are not theoretical examples. They are appearing, in public, on GitHub, every week.
I have spent the last few months building a catalog of them. The site is called Awesome Medical Tools, and it is a continuously curated list of every open-source medical tool I can find that is authored by a verified physician or physician-in-training. Each entry has a name attached, a credential attached, and a quoted line from the author's own GitHub bio that established the credential. Over three hundred tools are in the catalog today, growing monthly through an automated discovery, verification, and categorization pipeline with human review. The list is browsable interactively by specialty, training stage, and application type.
What medical school should teach
Medical training has, for good reasons, organized itself around skills that compound across a thirty-year career. Physical examination. Pattern recognition. Procedural technique. Case formulation. The hard conversation. I am not arguing for one less hour of any of those.
I am arguing for an hour, somewhere in the first two years of medical school, that introduces students to the idea that building is also a clinical skill. The students who will spend their careers in front of a screen typing into a chart deserve to learn that the screen is itself something they are allowed to shape. Few physicians will become full-time engineers. The point is different. Medicine should stop treating engineering as something done by other people on its behalf.
The clinicians in the catalog have figured this out, mostly on their own time, usually after their training was already over. Their work suggests that the standard discomfort of clinical software is not a permanent feature of medicine. It is a transition. The era of the physician builder has started. I think we should teach that.