Stop Lurking: Why Physicians Should Start GitHub Before They Feel Ready
Most physicians assume GitHub is for real developers. That assumption is costing medicine. Here is why the barrier is not skill, and what to do instead.
By Dr. Chukwuma Onyeije, MD, FACOG
Maternal-Fetal Medicine Specialist & Medical Director, Atlanta Perinatal Associates
Founder, Doctors Who Code · OpenMFM.org · CodeCraftMD · · 6 min read
Listen to this post
A colleague asked me last year why I bothered maintaining a GitHub profile.
She was a fellow Maternal-Fetal Medicine specialist. Smart, curious, already writing Python for her own clinical projects. But her code lived on her laptop, undocumented, unversioned, invisible to anyone who might build on it.
“It’s not ready,” she said.
That is the sentence I hear most from physicians who want to build things but have not started yet. Not “I don’t know how.” Not “I don’t have time.” The sentence is almost always some version of: it is not ready yet.
Nothing on GitHub is ready. That is the point.
Why the Barrier Is Not Skill
The technical floor for GitHub is not high. You need a browser and a GitHub account to create a repository and start documenting a project. You need Git installed and a few commands to version your work. Neither of those requires years of programming experience.
The real barrier is the assumption that GitHub is a place for finished things, maintained by people who already know what they are doing.
It is not. GitHub is full of half-built ideas, abandoned experiments, and work in progress. The difference between a physician-developer and a physician who wants to be one is often just this: the physician-developer committed something anyway.
What GitHub Actually Does for a Physician Who Builds
GitHub gives your ideas memory.
Without a system, a clinical project lives in scattered places: a Notes app entry, an email draft, a folder called “misc” on a desktop that has not been organized since residency. Those projects do not grow. They decay.
A GitHub repository is the opposite of that. It has a name. It has a history. It tracks every change you make and when you made it. It can be private or public, shared with a collaborator or kept for yourself.
More importantly, it gives unfinished work a legitimate home.
You do not need to ship something to benefit from version control. You benefit from it the moment you stop losing work to entropy and start building on the same foundation across time.
The Clinical Frustration Is Already There
Most physicians I know are sitting on at least one project idea tied to a specific recurring frustration:
A screening workflow that should take two clicks instead of ten. A counseling tool patients keep needing that does not exist in a usable form. A protocol buried in a PDF that should be a simple interactive page. A calculator that lives in someone’s memory instead of somewhere findable.
Those are not abstract complaints. They are product ideas. And GitHub is where a product idea becomes an organized project instead of a recurrent thought you cannot act on.
GitHub Rewards Visible Iteration
Medicine trains you to present finished thinking. You do not present a differential diagnosis to the patient and revise it out loud in front of them. You work through the uncertainty internally and present a plan.
GitHub works the opposite way. The commit history is visible. The README evolves. The issues log what was broken and what got fixed. The process is part of the product.
That is a healthy shift for physician-developers.
Because the path from clinical insight to useful tool is not a straight line. It loops. It revises. It requires showing other people something imperfect and getting their response. GitHub is built for that kind of work in a way that a laptop hard drive is not.
You Do Not Need to Start with AI
One of the assumptions that stalls physicians is the idea that GitHub for doctors means building a neural network.
It does not.
The most useful thing a physician-developer can commit to GitHub in the first month has nothing to do with machine learning. It might be a Markdown document organizing a protocol. A simple HTML page turning a static guideline into something interactive. A Python script that automates one repetitive task.
The point is not sophistication. The point is ownership. Getting one project into a repository and learning how to maintain it is the prerequisite for everything else in this space.
A Better First Question
Instead of asking “how do I become a software developer,” ask a different question:
What clinical frustration do I understand well enough to turn into a small project?
That question has a specific answer. And that answer is where you start.
The next post in this series walks through exactly what to do in your first week on GitHub as a physician. If you are already past setup and want to know what to build, go to three GitHub projects physicians can actually finish.
Keep Going
If GitHub has felt like a place for other people, start there anyway. The point is not to look established. The point is to begin building with structure.
Next, read GitHub for Physicians: Why Version Control Changes How You Build.
If you want the practical version immediately after that, go to Your First Week on GitHub as a Physician: A Practical Starter Plan.
Doctors Who Code Series
This post is part of the Doctors Who Code series, a practical roadmap for physicians who want to build software, understand clinical data, and move into medical AI without hype.
Newsletter
Enjoyed this post?
Get physician-developer insights delivered weekly. No hype. No filler.
Powered by beehiiv
Related Posts
Three GitHub Projects Physicians Can Actually Finish
Your First Week on GitHub as a Physician: A Practical Starter Plan
GitHub for Physicians: Why Version Control Changes How You Build
Chukwuma Onyeije, MD, FACOG
Maternal-Fetal Medicine Specialist
MFM specialist at Atlanta Perinatal Associates. Founder of CodeCraftMD and OpenMFM.org. I write about building physician-owned AI tools, clinical software, and the case for doctors who code.