A medical student’s first code. Here’s what he learned.

Why a medical student would code in the first place

Medicine is already an information job wearing a white coat. We collect histories, interpret labs, reconcile meds, document plans, and coordinate care across
a small galaxy of systems. Codingbasic programming, not billing codescan turn you from a passive user of technology into a slightly more dangerous (and
therefore more useful) participant in shaping it.

The student didn’t wake up yearning to become “a doctor who also debugs.” He just noticed a pattern: the tasks that drained the most time were the ones
computers are good atrepetition, organization, and consistent rules. Humans excel at meaning. Computers excel at “do this 4,000 times and don’t complain.”

In healthcare, the “simple” work is rarely simple

Your dataset might look harmless: columns labeled “BP,” “HR,” “Date,” “Notes.” Then you open it and find “120/80,” “120-80,” “120 over 80,” and one entry
that appears to be a phone number. Coding becomes less about fancy algorithms and more about making reality fit a rulebookwithout lying about it.

Choosing the first project: start boring, stay alive

His first mistake was wanting the script to do everything. He wanted it to clean data, calculate averages, flag outliers, generate plots, andif possible
resolve the emotional toll of third-year rotations.

Instead, he learned the first law of clinical programming:
start with a problem you can explain to a sleep-deprived classmate in one sentence.

• Too big: “Build an app to predict readmissions.”
• Just right: “Turn a CSV of vitals into a clean summary table and a couple charts.”

Boring projects are beautiful because they have clear success criteria. If the output table is correct, you win. If it isn’t, you know exactly what “wrong”
looks like. That’s rarer in medicine than we admit.

The first code looked like a note written at 2 a.m.

The student’s script started as a pile of lines that made sense only to himlike a SOAP note where the Assessment is “???” and the Plan is “monitor vibes.”
Then he met his first real teacher: the error message.

Debugging is clinical reasoning with less caffeine and more punctuation

Debugging felt familiar in a weird way. A program fails, you gather clues (error text), form a differential (possible causes), test hypotheses (change one
thing), and reassess. The difference is that the program is brutally honest. It does not nod politely while you explain your reasoning. It simply crashes.

He discovered quickly that the most common “bug” is not a complicated technical issue. It’s a mismatch between what you think the data is and what it
actually is. That’s also… most medical mistakes.

Lesson #1: Data is a patienthandle it like one

The moment you touch health data, you inherit obligations. Even if you’re “just a student.” Even if it’s “just a spreadsheet.” Privacy isn’t an
afterthought; it’s part of the design.

He learned to ask early:

• Do I have permission to use this data for this purpose?
• Can I work with de-identified or limited data instead of identifiable data?
• Where is the file stored, and who can access it?
• How will I document what I did so it’s auditable?

This is not paranoia. It’s professionalism. If you wouldn’t leave a patient chart on a cafeteria table, don’t leave a dataset on an unencrypted laptop.

Lesson #2: Interoperability is the difference between “possible” and “practical”

In a fantasy world, the student could pull exactly what he needed from an EHR with clean labels and standardized units. In the real world, he learned that
data often lives in silos, formatted differently in each system, and guarded by understandable constraints.

That’s why modern interoperability standards matter. He kept hearing the same phrasesFHIR, APIs, SMART on FHIRand realized they weren’t buzzwords. They
were the reason health software can sometimes talk to other health software without resorting to exporting PDFs and praying.

What “FHIR” meant to him (in plain English)

FHIR is a standard for exchanging health information electronically using modern web patterns. The student didn’t need to memorize every resource type.
He just needed the concept: standardized data structures make it easier to build tools that work across environments.

Why “SMART on FHIR” felt like a superpower

SMART on FHIR is about launching apps securely inside clinical workflows and pulling standardized data through FHIR APIs. For a student, that translated to
a hopeful idea: “Maybe one day I can build something that works in a real clinic without begging IT for a one-off export every week.”

Lesson #3: The user is not you (and future-you is also not you)

His script ran fineuntil he tried to show it to a classmate. Suddenly nothing worked. A file path broke. A column name differed by one invisible space.
The date format changed because the spreadsheet was saved from a different computer.

This is where medicine prepared him again. Clinical tools succeed when they fit workflows. The “right” solution isn’t the clever one; it’s the one people
can actually use without a support hotline staffed by the developer’s mother.

He started writing code like he wrote orders

Clear. Specific. Defensive.

• Check assumptions: “If the BP column is missing, stop and explain.”
• Validate inputs: “If a systolic is 800, flag it, don’t average it.”
• Document intent: Comments that explain why, not just what.

Lesson #4: Clinical decision support is regulated for a reason

About two weeks in, he had a dangerous thought: “What if my script could recommend follow-up intervals based on blood pressure trends?”

That’s when a mentor introduced him to the grown-up world of clinical decision support (CDS): when software influences diagnosis, treatment, or triage,
the stakes change. There are ethical expectations, validation requirements, and regulatory frameworks that exist precisely because “I tested it on three
patients and my roommate” is not evidence.

The student didn’t abandon the idea. He reframed it. Instead of recommendations, his script generated a neutral summary:
trends, missing data, and guideline-relevant thresholds highlighted for clinician review.

Lesson #5: AI can helpbut it can also hallucinate like an exhausted intern

He tried using an AI assistant to speed things up. Sometimes it was magical: it explained a confusing error or suggested a cleaner way to parse dates.
Other times, it confidently invented functions that didn’t exist. In medicine, we call that “confabulation.” In programming, we call it “Tuesday.”

He learned a simple rule: AI is a drafting tool, not an authority. If the output affects patient care, it requires the same skepticism
you’d apply to an unverified history from a confused chart note.

Lesson #6: Version control is the charting of code

At first, his file names looked like a hospital problem list:
final.py, final_final.py, final_FINAL_really.py.
Then he discovered version control and realized he’d been practicing unsafe software medicine.

With version control, he could:

• See what changed and why (like reading prior notes, but less passive-aggressive).
• Roll back mistakes (imagine that feature in real life).
• Collaborate without overwriting each other’s work (also imagine that feature in real life).

Lesson #7: Small tools can have outsized impact

His final script wasn’t flashy. It cleaned vitals, standardized formats, flagged suspicious values, and produced a short report.
But that “boring” tool saved hours, reduced transcription errors, and made the QI project feasible.

That’s the secret: in clinical informatics, a tiny improvement repeated a thousand times becomes a big improvement. A five-minute task done 200 times a month
is a system problem. Coding is one way to treat system problemscarefully, ethically, and with respect for the humans inside the system.

Practical takeaways for any medical student writing their first code

1) Pick a workflow you already understand

If you’ve lived the pain, you’ll design better relief. Start with something small: data cleaning, scheduling, simple analysis, or automating a repetitive
document task (within institutional rules).

2) Treat privacy and security as requirements, not “nice-to-haves”

Work with the minimum necessary data. Prefer de-identified datasets when appropriate. Store files securely. Follow your institution’s policies.

3) Aim for reproducibility

Write instructions so another student can run it. Hard-code less. Validate more. Print friendly error messages. Your future self is a different person,
and that person is tired.

4) Learn the “healthcare plumbing” basics

Even if you never build an EHR app, understanding standards like FHIR and the idea of secure API-based access will make you a better clinician and collaborator.

5) Keep the humor, keep the humility

Medicine teaches you to take responsibility. Coding teaches you to accept that you will be wrong… repeatedly… until you aren’t.
Combine both and you get something powerful: a clinician who can improve care without pretending to be infallible.

500-word field notes: what it felt like to write that first code

The first night he coded, he expected a clean learning curve. He got something more like an EKG during a seizure: peaks, drops, and a lot of staring.
He opened a blank file and felt the same pressure as opening a new patient chartexcept the “patient” was a problem he created for himself on purpose.
Which, in hindsight, is a very medical-student hobby.

The weirdest part was how personal the mistakes felt. When a program failed, it didn’t fail politely. It failed loudly, with error messages that sounded
like a grumpy attending: “TypeError: you can’t do that.” He’d read that debugging was normal, but experiencing it was different. In medicine, confusion
can be social; you can hide it behind a nod. In code, confusion is binary. Either the thing runs or it doesn’t. There’s no “partial credit for confidence.”

Then something clicked: each bug was a clue, not a verdict. He started to enjoy the detective work. He’d change one line, rerun, watch it break in a new
way, and think, “Okay, progress. At least it’s breaking differently.” That’s not far from clinical caretreat, reassess, adjustexcept the patient is a
spreadsheet and it never asks for warm blankets.

He also noticed a shift in how he looked at hospital technology. Instead of assuming the EHR was an unchangeable force of nature (like gravity or
hospital cafeteria eggs), he began to see it as a set of decisions made by humanssometimes good, sometimes questionable, always improvable. When a checkbox
made no sense, he stopped thinking “I’m dumb” and started thinking “This interface wasn’t designed for how clinicians actually work.” That mindset is a
quiet kind of empowerment.

The biggest emotional surprise was how coding restored a sense of agency during rotations. Third year can make you feel like a passenger in a system that
runs on momentum. But here was a task where effort produced visible improvement: faster output, fewer errors, clearer results. It was a small island of
cause-and-effect in a sea of “we’ll see what the labs show tomorrow.”

He didn’t become a software engineer. He became something more realistic and more useful: a medical student who could build small, safe tools, speak more
fluently with IT and informatics teams, and ask better questions about data quality and workflow fit. His first script didn’t cure disease. It reduced
frictionand in medicine, reducing friction is not trivial. It’s often the difference between a good idea and a thing that actually happens.

And yes, he still has final_final_really.py somewhere. It’s a memorial. Like keeping your first stethoscope: not because it’s the best, but
because it reminds you you started, you struggled, and you learned.

Conclusion

A medical student’s first code isn’t about becoming “a coder” overnight. It’s about learning a new form of problem-solving, respecting the responsibilities
that come with health data, and realizing that many frustrations in healthcare are, at their core, system design problems.

Write small code. Validate it. Document it. Ask who it helps. Protect privacy. And keep your sense of humorbecause the compiler has none.