Why Doctors Should Learn to Code

Last year I reviewed a quality metrics report that flagged my preterm birth rate as an outlier. The number was correct. The denominator was wrong. The report treated a high-risk referral practice like a general OB panel, then presented the result as if the problem were clinical instead of computational.

I knew the logic was wrong. I could not fix it. I did not control the query, the data model, or the dashboard that turned a bad assumption into an institutional fact.

That is the real argument for physicians learning to code. It is not about career reinvention. It is about refusing to stay trapped on the downstream side of systems we understand better than the people who build them.

The Framing Is Wrong

When people hear “doctors should learn to code,” they often imagine an exhausted physician trying to become a part-time software engineer after clinic. That is the wrong frame. I am not arguing that every physician should become a full-time developer.

I am arguing that physicians should understand enough code to inspect, question, and improve the digital systems shaping patient care. In modern medicine, technical illiteracy is a strategic disadvantage.

What Coding Actually Gives You

Coding gives physicians leverage in three places where modern practice breaks down.

First, it gives you access to your own data. A physician who can write a basic script can audit outcomes, inspect denominators, clean messy exports, and ask a better question than whatever canned report the EHR decided to surface. You already know what matters clinically. Code lets you test it directly.

Second, it gives you the ability to automate repetitive work. Administrative burden is not just a staffing problem. It is often a workflow design problem hiding inside repetitive, rule-based tasks that should have been automated years ago. Follow-up reminders, report generation, chart abstraction, intake logic, quality audits. These are solvable problems.

Third, it gives you the ability to build tools calibrated to real practice. A physician who codes can build a narrow, useful tool for a real problem without waiting for a vendor roadmap, a departmental committee, or a startup pitch deck. That is not theoretical. It is how clinical software should begin.

Why Physicians Matter Here

Most healthcare software fails for a simple reason. The people defining the workflow are too far from the bedside, and the people at the bedside cannot modify the system.

That gap creates bad dashboards, brittle automation, alert fatigue, and AI tools that sound impressive in demos but collapse in real clinical use. Physicians who code sit in the middle of that gap. We can see the workflow, name the failure mode, and build with the right constraint set from the start.

This matters even more as AI moves deeper into medicine. A physician who understands both the clinical use case and the technical architecture can participate in model evaluation, governance, and deployment with actual authority. Everyone else is reacting to tools they did not shape.

Start Smaller Than You Think

The goal is not to master computer science before you build anything useful. The goal is to solve one real problem in front of you.

Start with the spreadsheet you keep exporting by hand. Start with the reminder workflow your staff repeats every day. Start with the quality metric you do not trust. Start with the counseling calculator you wish existed in a form you could actually use at the bedside.

That is also why I keep arguing for disposable software. In Inbox Detox: Two Evenings of Disposable Software, I wrote about building a narrow internal tool to solve a specific operational pain point instead of waiting for a polished product, a formal roadmap, or somebody else’s permission. That is often the right starting point for physician-builders.

InboxDetox did not need to become a venture-backed platform to be valuable. It just needed to reduce friction in a real workflow. That is the mindset I want more physicians to adopt. Learn enough code to solve the problem in front of you, prove that the workflow can be improved, and let usefulness come before permanence.

That is how physicians learn to code in a way that sticks. Not through abstraction alone, but through ownership.

The Real Choice

Medicine is already being rewritten by software. The question is not whether code will shape clinical practice. It already does.

The real question is who gets to shape the code. If physicians remain technically passive, the future of medical workflow will be designed mostly by people who do not carry clinical responsibility. I do not think that is acceptable.

Doctors should learn to code because medicine now depends on systems, and systems should be shaped by people who understand what is at stake.