Improving medical students' lives with code

MP #4: Code is just one thing to think about in a real-world project

Note: This is an important topic that could benefit from a wider variety of perspectives. If you have any insights to share about this post, please feel free to do so.

I get lots of questions from people whose interest in learning to code centers around a desire to address an inefficiency they’ve identified in their field. Sometimes these are clearly business-focused problems, where if the project was built someone would just make more money. But often times these are projects that address very real pain points for people, that make their lives less enjoyable on a daily basis. These are projects I’d love to see built, and hearing about these projects is one of the main reasons I continue to care so deeply about helping other people learn to code. At the same time, I also regularly encourage people to keep thinking beyond the code.

When people reach out for advice I usually steer them to a general resource, such as one I wrote a while back about how to find work as a (new) programmer. Sometimes, however, I end up in interesting conversations about work that people are really passionate about. Last week, I had an inspiring video chat with a fourth year medical student who’s working on a compelling project. The way they’re thinking about the project, and the things we talked about, are representative of what comes up in a lot of these conversations. I want to share some aspects of our conversation because it’s an interesting project in its own right, but also because it might help people think about how to approach their own projects.

Articulating the problem

In case you’re unfamiliar with how medical school works, most fourth year students are currently going through the “matching” process. They’ve already applied to a number of different residency programs. Currently, they’re interviewing with the programs they’ve applied to. Later this spring, they’ll find out which programs they’ve matched with. It’s a stressful process. There are elements not fully in students’ control, and it’s a critical part of becoming a licensed, practicing physician.

As in many fields, there’s no shortage of bureaucracy in medical school. When faced with bureaucracy, I’ve seen people respond in three ways: 1) dejectedly accept the decisions of those in charge, from burnout or apathy; 2) mild annoyance and complaining, but no real sense of agency; 3) get fired up, find ways to push back against noncritical bureaucratic work, and focus on what really needs to get done. There’s actually a fourth group, where people identify systemic issues and respond in a way that helps others avoid the same kind of bureaucratic inefficiencies they’ve had to face. The person I spoke with is firmly in this last group, and it’s a lifelong joy to meet these people.

They clearly articulated a number of problems that come up in medical school in the 2020s. I’ll focus on one issue they described, which is relevant to their research project:

When doing research, both for learning purposes and choosing which residency programs to apply to, students need to sift through a wide variety of resources: journals, popular articles, university and hospital websites, personal websites, social media posts, and much more. Almost everyone compiles these resources into their own Excel document, Word document, or some other tracking system they’re familiar with.

There’s a tremendous amount of repeated work being done here, which represents time and effort that could be better spent on learning.

The project

The person I spoke with is working on a graduation project that aims to demonstrate one way the research process can be made more efficient. They have a small team that is pulling a variety of research data into a centralized data store, and allowing end users to access all that information in one place. Some of the data is being pulled in manually, but the goal is to automate as much of this data collection as possible.

The natural (but wrong) questions

They posed the same kinds of questions I often hear from people working on projects like this:

I learned the basics of Python. Is that enough? What else should I learn?

Can you recommend some learning resources? What books should I read? What courses should I take? Are there any certifications I should get?

These are natural questions to ask, but often times I don’t think they’re the right questions to ask at this point. These questions assume you’re going to do all the building; they assume you’re going to be the one to write all the code for the project.

The right questions

I asked a few questions of my own in return before going any further:

Can you describe your project in one or two sentences?

Again, in one or two sentences, how will you know if your project is successful?

And finally, what’s the narrowest version of your project that can be considered successful for this initial phase of work?

These questions get at the heart of a project. They look beyond lines of code, and help define the purpose and scope of the project.

I didn’t record the responses well enough to report them here, but to this person’s credit they were able to answer each of these quite clearly.

Sketching it out

I wanted to make sure I understood the project accurately, so I sketched out a diagram of how I envisioned this project. Here’s a cleaned up version of that first sketch:

Diagram showing the flow of data from external data sources, through a manual and automated data collection system, to an internal data store, and ending in an Excel document.

The raw data is a mix of structured and unstructured data, spread across a variety of sources. Right now every medical student has to deal with this raw data on their own. Or, perhaps they team up with a few others and recreate their own small version of what you see here.

This project aims to develop a set of scripts that pull information from these sources into a centralized data store, supplemented by some manual data collection work. The information is then written to an Excel document that people can work with as they need.

New questions and observations

This diagram led to some clarifying questions, which then led to a focus on some issues that are more important than specific coding resources in a project like this. One of my main questions was, “Why is the whole project ending up in an Excel document?” Sometimes that’s what people want, because their next steps require them to work in Excel. But often times it’s because Excel is the only data viewing tool that people are familiar with.

This project would probably best be served as a website. A modern website can be thought of as a universally accessible frontend to a database. Here’s a modified version of the previous diagram, showing how this project might be structured in its next phase of development:

Diagram showing data flowing from external sources, into the backend of a website, and also showing that people can download an Excel doc, Word doc, contact list, or PDF report from the website.

You can build a website so it shows people exactly the data they need, and outputs the data in any format they want to work with. You can let people view the data in their browser, but also give them the option of downloading the data as a spreadsheet, a PDF file, or any other format you want to offer your users. You can control access to some or all of the data.

You can also combine the viewing and scraping interfaces in one place. For example, you can give people the option of uploading any data they know of that’s missing from the database, and you can run any validation you need on this user-submitted data. In this second diagram, everything in the gray box would be part of the website.

What’s your focus?

Most people can’t perform at a high level as a physician, and also serve as the technical lead on a significant project. Is it worthwhile for medical students to learn programming? Of course it is, if they’re interested.

A reasonable familiarity with programming allows you to:

  • have a better sense of what kinds of automation are possible;
  • more accurately assess the difficulty of automating any given process;
  • communicate in an informed way with teams of developers;
  • build proof-of-concept projects, that move more quickly to the next phase of development.

What next?

The person I spoke with is going to finish their project as a proof of concept. I think it’s great work. It shows how much a tool with a specific purpose can do to make people’s work more efficient, and more effective. It shows that people with a reasonable understanding of modern software development practices can have a meaningful impact on specific problems in medicine.

It’s extremely doubtful that this one person will be able to create and maintain an effective, functional tool for the long term. Again, to their credit, they’re well aware of this. Most of these projects either require a small dedicated team that can build, run, and maintain an open project over the long term, with all that an open source project entails. Or, it needs to be a funded project where a software development shop is contracted to build and maintain the project. This is a great solution when the funding is available.


When people with expertise in a specific domain area identify an inefficient process that can be automated, the end result isn’t always that people lose jobs. Often times the result is an improvement in people’s ability to focus on their main job, without the distraction and frustration of rote, mundane, tedious workflows. Medical students are overloaded in many ways; projects that make their work more efficient are well worth pursuing, and have the potential to have far-reaching impact.

We all get excited about coding up a solution; it makes us feel smart, and gives us a wonderful feeling of satisfaction. A moderate degree of coding knowledge can let people build a proof of concept project, or even a full MVP. But the next phase, building out a solution that works correctly for all users, for the long term, can easily become full time work that requires experienced developers and project management skills. Don’t let this hold you back, but definitely keep a grounded perspective on your long term goals and vision once your project proves its worth.

Note: If you’re familiar with an existing project that has similar aims to the one described here, please mention it. I’m hoping to write a followup post after this person’s research project is complete, and they’ve published their work. This post was written with their approval.