As an MD-PhD student whose research is more focused on machine learning and algorithmic development than on biology outright, I've spent a fair amount of time thinking about the seeming disconnect between the skills I need for research and the skills I'll need to provide good clinical care as a future doctor.
My research focuses on building predictive models of treatment response and relapse in pediatric cancer, so I spend most of my time writing R and Python code that wrangles, visualizes and models data collected from patients. Yet despite spending most of my time programming, I know for a fact that coding is not in the top 20 (...or maybe top 100) skills needed to care for patients in a clinical environment.
Still, a few years of experience in both contexts has shown me that some lessons I've learned from being a programmer generalize wonderfully into my life as a medical student -- and bode well for my future balancing these two worlds.
Here are a few of my insights:
Break problems into sub-problems.
With any data science or programming project, it's critical to break your overall objective into a series of smaller, more manageable objectives that you can handle one at a time. For example, if you're implementing an algorithm that has three distinct steps, an optimal strategy often involves writing code that implements each step separately first, then writing a function that combines them. By doing so, you can keep your code organized, efficient and easy-to-understand.
I've found myself applying the same principle in medicine. For instance, when taking a medical history, it helps to approach the conversation in several discrete steps--i.e. the "history of present illness," "past medical history," "social history," etc.--each of which corresponds to a small part of the patient's background and needs. That way, I'm able to reliably obtain all of the information I need without leaving out anything important.
Memoization (not memorization!).
In computer science, "memoization" is a coding technique that can be used to speed up an algorithm by reusing the answers to problems that have been solved before. In other words, a "memoized" algorithm will only take the time to solve a problem from scratch once -- and every time the same problem is encountered in the future, it will simply look up the old solution (like a "memo") instead of re-solving the problem from the beginning a second time. This means that the algorithm will solve problems slowly the first time, but will be much more efficient at solving the same problems in the future.
In many ways, I feel like being a medical student is a master class in memoization. A lot of the things you learn are overwhelming at first, and you have to master the small steps to move on to the bigger picture. For example, during my first quarter of medical school, I struggled to hear any heart sounds through my stethoscope at all, and I had to practice with my classmates multiple times before it finally clicked. They showed me what stethoscope placement worked for them, and if it worked for me, too, I made it part of my process. A year later, and a full cardiac exam -- including listening for murmurs, rubs and gallops in a patient's heartbeat -- became reflexive to the point that I barely had to think about it. Despite being slow at first, I eventually mastered each step by developing a fully "memoized" approach that combined what had worked for me (or my classmates) in the past.
Always check for edge cases.
In programming, "edge cases" refer to situations that you wouldn't normally expect. For instance, in a computer program that compares two numbers and tells you which one is larger, an "edge case" might be what happens when the two numbers are identical (because neither one is technically larger than the other). Generally, thinking about and testing for edge cases is important for ensuring that your code doesn't break when it sees something unexpected--which can cause catastrophic results!
Accounting for edge cases in medicine requires the same degree of creativity and forward-thinking as it does in programming. Often, physicians have to engage in "what if" thinking to account for multiple diagnostic possibilities even when only one or two of them seem likely. For example, my advisor and I had a case in which a patient developed a runny nose the day before starting a course of chemotherapy. Based on the patient's past history of seasonal allergies and the high pollen count that day, most signs seemed to indicate that there was nothing to worry about. But--in order to rule out the unlikely "edge case" that the patient had contracted an acute viral infection that could become serious when his immune system was suppressed by chemotherapy--my advisor made sure to run tests for several common bugs before starting treatment.
Despite the seeming differences between computer science and medicine, I've come to appreciate their many similar ways of thinking. Among these are a shared commitment to creativity, thoughtfulness and efficient problem-solving. For these reasons and more, I'm hopeful that--even though I'm unlikely to use my coding skills on the wards directly--being a programmer will ultimately make me a better physician.
Stanford Medicine Unplugged is a forum for students to chronicle their experiences in medical school. The student-penned entries appear on Scope once a week during the academic year; the entire blog series can be found in the Stanford Medicine Unplugged category.
Tim Keyes is an MD/PhD student in Stanford's Medical Scientist Training Program. He likes microglia, snowmobiles, pop music written for teenage girls, and going on terrible first dates. Follow him on Twitter at @timothykeyes
Photo by Zan
