Articles | Vidun Wedagedera | Cambridge Medical Student

Why Medics Should Learn Software Engineering

Sun, 26 Jul 2026 00:00:00 +0000

At the beginning of fourth year, I started learning software engineering.

Medical school was not exactly leaving me short of things to do. But my interest in medtech, particularly atrial fibrillation ablation, conversations with other students and the problems I kept noticing in general practice were all pushing me towards the same conclusion: I did not only want to understand healthcare. I wanted the ability to build within it.

I am now around halfway through CS50 and CS50 AI. I have built this website from scratch, although I have not yet built a full application or serious software product. Separate articles on both courses will come once I have finished them. For now, I am writing from the middle of the process rather than pretending I have reached the end.

My argument is not that every doctor needs to become a professional software engineer. Every medic should have a basic level of technical literacy: enough to understand code, write small programmes and analyse data. Medics who genuinely enjoy building should go much further.

Healthcare is becoming increasingly dependent on software. The people who understand its problems most closely should have more than the ability to point at those problems and hope somebody else builds the solution.

Knowing how to build changes what you notice

Medical students are exposed to potential healthtech problems constantly.

We see information copied between systems, decisions delayed by missing data, repetitive work performed manually and processes that survive mainly because everyone has become used to them. I do not want to describe the specific problems I have noticed in general practice, but the broader pattern is difficult to miss. Healthcare contains a remarkable amount of intelligent human labour being spent on tasks that do not always require intelligent human labour.

The obvious response is to tell a software engineer.

That can work. Excellent healthcare technology is almost always multidisciplinary. But there is a difference between being able to describe a frustration and being able to translate it into a technical problem, investigate whether it is actually solvable and build an early version of the solution.

Paul Graham, the co-founder of Y Combinator, argues that the best startup ideas usually emerge from problems founders have experienced themselves. They are not manufactured by sitting in a room and attempting to think of something that sounds sufficiently disruptive. They are noticed by people whose experience has prepared them to recognise that something is missing. His version is: “Live in the future, then build what’s missing.”

Medicine gives people one half of that preparation. Software engineering gives them the other.

Clinical training teaches you how healthcare actually behaves rather than how a process diagram says it behaves. You see which information matters, where uncertainty enters and why a minor inconvenience can become clinically important. Learning software then changes the questions you ask about those observations.

A clumsy workflow stops looking like an unavoidable feature of medicine and starts looking like a sequence of inputs, decisions and outputs. Repetitive documentation becomes a problem of structured data and system integration. A delay may turn out to be an information problem rather than a medical one.

You begin to see more things as buildable.

Graham makes a similar point about combining programming with another domain: once you understand both, you are more likely to notice problems that software could solve. Knowing how to build also shortens the distance between an idea and an experiment. Instead of saying, “Someone should make this”, you may be able to produce a crude first version and discover whether anybody actually needs it.

The first version will probably be unimpressive. This is useful. It is much cheaper to discover that an idea is bad when it is an ugly prototype than after a large team has built a beautiful product that nobody wants.

The clinician-founder advantage

I think some of the best healthcare founders will be people who have lived inside healthcare.

This is not because doctors understand the whole system. We do not. A clinician may understand a consultation or procedural pathway deeply while knowing very little about procurement, regulation, cybersecurity, hospital finance or the practical difficulty of maintaining software across hundreds of organisations.

The advantage is narrower, but still important: clinicians possess situated knowledge.

They know what a decision feels like when the evidence is incomplete. They know which interruptions are merely irritating and which create risk. They understand that a tool can perform brilliantly in a paper yet fail because it arrives at the wrong point in the workflow, asks for information nobody has or produces an answer that does not change what happens next.

That knowledge is difficult to acquire from market research alone.

The strongest clinician-founders will not be doctors who assume that medical knowledge makes them naturally good at everything else. They will be people who combine clinical experience with enough technical depth to work properly alongside software engineers, designers, researchers, patients and operators.

The aim is not to eliminate the engineer from healthcare. It is to eliminate the situation in which the clinician arrives with a PowerPoint, the engineer arrives with an architecture diagram, and both leave believing the other person understood them.

A medic who can code can participate differently. They can judge what is technically trivial and what is genuinely difficult. They can interrogate assumptions, inspect data and prototype an idea before asking a team to spend months on it. They can also recognise when the sensible decision is to stop building.

That last skill may be the most commercially valuable one.

Where My Interests Are

My interest in this began partly through medtech in atrial fibrillation ablation. Cardiac electrophysiology is a useful example because it produces large amounts of complex physiological data, while clinical decisions still depend on anatomy, procedural context and individual patient factors.

Artificial intelligence research in electrophysiology already includes AF detection, prediction of outcomes and potential support inside the electrophysiology laboratory. A 2025 scientific statement from the European Heart Rhythm Association, the Heart Rhythm Society and the ESC Working Group on E-Cardiology reviewed work across AF management, sudden cardiac death and electrophysiology procedures.

It also identified substantial gaps.

The statement introduced a 29-item checklist because studies were not consistently reporting important details about their datasets, participant populations, validation methods, performance and reproducibility. In other words, impressive model performance does not automatically tell us whether a system will improve care for real patients.

This is precisely why healthcare technology needs people who understand both the clinical problem and the technical method.

A software engineer may build an excellent model without fully understanding whether its output changes a meaningful decision. A clinician may recognise an important decision but underestimate bias, data quality or the difference between an algorithm working retrospectively and a product working safely in practice.

Neither perspective is enough alone.

Learning software engineering will not make a medical student capable of independently building and validating an AI system for AF ablation. It can, however, make them far better prepared to ask what data the model learned from, what outcome it optimises, how it fails and whether that outcome is one patients or clinicians actually care about.

Technical literacy is therefore not only about creating products. It is also a defence against being excessively impressed by them.

The future may be agentic but medicine must remain human.

I think the next major shift will be towards more agentic software: systems that do not simply generate a single answer, but can plan and carry out a sequence of linked tasks.

In healthcare, that could eventually mean software gathering relevant information, coordinating parts of a workflow, drafting documentation, tracking results and prompting the next action. The potential is enormous because so much clinical time is currently lost between the important parts of care.

But the question is not simply whether a task can be automated. It is whether it should be, under what conditions and with whom remaining accountable.

The closer software moves towards clinical decisions, the more dangerous it becomes to treat medicine as a tidy optimisation problem. Patients do not arrive as complete datasets. They may value outcomes differently. They may need an explanation, reassurance or the sense that another human being has taken responsibility for what happens next.

Technology cannot replicate the full empathy and human nature of medicine. Nor should that be its goal.

The 2019 Topol Review described one of the main opportunities of healthcare technology as the “gift of time”: automation should reduce avoidable work so that clinicians have more time for trust, presence, empathy and communication. It also warned that new technologies require clinical validation and should not dehumanise care.

That is the standard worth using. Good healthcare software should not make the patient–clinician relationship more efficient in the sense of making it smaller. It should remove the work that prevents the relationship from existing properly.

The World Health Organization similarly argues that AI for health must place ethics and human rights at the centre of its design and use, with clear human responsibility and routes for accountability when systems cause harm.

Doctors need technical knowledge partly so that these decisions are not made after a system has already been built. Clinical judgement, patient needs and ethical constraints should shape the architecture from the beginning.

Not every medic needs another degree…

The strongest objection is obvious: medical education is already overloaded.

Students are expected to learn an enormous body of science, develop clinical skills, complete placements, prepare for examinations and somehow remain functional human beings. Adding “become a software engineer” to the compulsory list would be unrealistic and probably produce a generation capable of writing mediocre Python while forgetting the causes of hyponatraemia.

That is not what I am proposing.

Basic technical literacy should become normal. A medic should be able to understand what code does, write small programmes, work with data and have a sensible conversation about how software systems are built. These skills matter even for doctors who never create a company. They will increasingly need to evaluate digital tools, understand their limitations and work safely in systems shaped by algorithms.

NHS workforce reviews have already argued that healthcare professionals need broader digital capabilities and that technology requires an appropriately trained workforce if it is to benefit patients.

Going further should be a choice.

Software engineering is difficult, and becoming good requires sustained effort. Medics should pursue it deeply because they enjoy building, not because attaching “AI” to their CV currently seems wise. Enjoyment matters because the work involves long periods of confusion, debugging and discovering that the computer has followed your instructions with far greater precision than you intended.

For those who do enjoy it, courses such as CS50 provide a strong starting point. The immediate goal does not need to be founding a company. It can be writing a small programme, analysing a dataset or building something useful for yourself and your friends.

The important step is to begin acquiring agency.

Clinical medicine allows a doctor to create profound value for the patient in front of them. Software creates a different kind of leverage: something useful can be deployed repeatedly, across clinicians, patients and healthcare systems, without its creator being present for every use. That does not guarantee impact. Most software will not affect millions of people, and scale can distribute a bad decision just as efficiently as a good one.

But the possibility matters.

Concluding thoughts

Medical training teaches us to recognise disease, uncertainty and failures in care. Software engineering can give some medics the ability to turn those observations into something tangible, testable and potentially scalable. In summary, I think the future of healthcare should not be built by doctors alone, but more of it should be built by doctors who know how to build.

How to Do Really Well in Clinical Medicine Exams

Fri, 24 Jul 2026 00:00:00 +0000

At the beginning of clinical school, we were given a piece of advice that sounds almost impossible to disagree with: go into the wards every day, see patients and research the conditions you encounter. We were told by our dean that doing this consistently was the route to a distinction (roughly, finishing within the top 15% of the year).

There is a lot that is right about this. It will probably make you a better doctor.

But if you do only this, I think you are more likely to finish in the bottom 15% than the top.

The problem is not the wards. Learning medicine and performing well in medical school examinations are related, but they are not the same task. Patients do not follow textbooks. Exams, by necessity, mostly do.

In my fourth year, the assessment consisted of a three-hour single best answer paper covering almost every specialty we had studied, followed by five examination and five history-taking OSCE stations. Cambridge’s current course information still describes Year 4 assessment as a written test spanning the major clinical specialties and an OSCE assessing practical, examination and communication skills.

Once I understood the format, the basic principle became obvious: revise according to the examination you are actually going to sit.

PS. All the resources that I used/mention are uploaded onto the resources page of the website. I hope these are of some use to you all.

PSS. Perhaps the most important factor that contributed to my success is mentioned at the end (and no, its not more revision).

The system that nearly burnt me out at the start.

The transition from preclinical to clinical medicine was surprisingly disorientating. Preclinical learning was mostly structured around lectures. In clinical school, much more of the responsibility suddenly belonged to you.

I began by trying to learn everything properly. I used the Cambridge conditions list, made extensive notes, created my own Anki cards, completed PassMed questions, went into placement and tried to maintain the rest of my life — including competing in badminton at county and national level.

The plan looked excellent on Notion. This was part of the problem.

The conditions list on my Notion page.

Within weeks, I had created a system capable of consuming every available hour while still leaving me convinced I was behind. Making comprehensive cards before testing myself meant spending enormous amounts of time deciding what might matter. I was memorising clinical medicine as though I would later have to reproduce it in a preclinical essay.

But the 4th year exam consisted of a 1 3hr single best answer (SBA) paper and 2 sets of OSCEs. For any of these exams, I did not need to recite the textbook (unlike the essays in pre-clinical medicine). I needed to recognise presentation patterns, distinguish plausible options and retrieve the fact that separated the right answer from four nearly-right ones for the SBA.

Around January, I shifted towards learning through questions. At first, I planned simply to repeat my incorrect PassMed questions. Sometimes I got the same question wrong again; other times I remembered the answer because I recognised the wording.

Neither meant I had fixed the gap.

What actually works and how to smash the SBA.

Breakdown of the 4th year Cambridge SBA exam by specialty.

The method improved when I stopped treating a wrong question as something to repeat and started treating it as evidence.

Every incorrect answer had a cause. Perhaps I did not know the investigation of choice, confused two similar presentations or had forgotten an important contraindication. That missing concept — not the whole condition and not the original question — earned an Anki card.

The loop became:

answer questions → identify the precise knowledge gap → make a focused card → retrieve it later without the original question

My Notion notes remained useful as a reference. I organised conditions into pathophysiology, investigations and differentials, complications, and management. But the questions decided which parts needed to enter active memory.

Initially, I worked through one specialty at a time. Later, I mixed everything together so that practice resembled the real exam. By April or May, I had moved from roughly 50 questions per day to a strict target of 200.

That number is not sacred. The useful principle is that question volume only helps when mistakes generate learning. Two hundred questions completed on autopilot can become an elaborate way of clicking buttons.

This is more than enough to comfortably get >70% on the SBA. But if you want to be aiming for >80%, I recommend the following. At cambridge, the questions require you to think a little and carry out 2/3 steps before arriving at the answer, whereas PassMed (most of the time) just relies on rote memorisation. Because of this, I highly recommend doing all the moodle questions available and going through the reasoning behind answers to each question thoroughly, along with prioritising your revision around the conditions tested in these questions.

What to do on the wards?

This is not an argument for abandoning placement. Cambridge assesses attendance and overall performance on placements as well as formal examinations. More importantly, the wards teach things a question bank cannot: how illness varies, how patients describe symptoms, how uncertainty feels and how clinical teams make decisions.

But “go to the wards” is not yet a learning plan.

I found that one or two focused hours on most days could be enough if I arrived with a goal. A typical target was two examinations and one history. That is more useful than spending an entire day on a ward and hoping education happens to you.

Patients are not OSCE props. Practising clinically still requires consent, appropriate supervision and respect for confidentiality. GMC guidance is clear that patients should be comfortable with a student’s involvement and that students participate within suitable supervision. The aim is deliberate learning, not turning placement into a scavenger hunt.

How to smash the OSCEs.

In all honesty, I left concentrated OSCE revision quite late. I had practised examinations intermittently on the wards, and a mock in November forced me to learn the core cardiovascular, respiratory and gastrointestinal examinations properly. Surprisingly, much of that stayed in my memory.

Nearer the exam, I practised the sequences repeatedly with friends and, when no friend was available, on a pillow. The aim was to make the basic order automatic. In an OSCE, you do not want to spend your limited attention remembering what comes after inspection; you want to notice findings, communicate clearly and structure the viva.

I also benefited from a three-day gap between the SBA and my OSCEs. Some students had their OSCE the following morning, so I would not build an entire strategy around receiving the same kindness from the timetable.

The most important thing…

In my three pre-clinical years, I thought revising all day, every day during Easter term was the best way to get as much information as possible into my brain before the exam. Very wrong. You need breaks. Otherwise, you cannot be efficient, your memory gets worse, and you simply cannot think straight, at least that was the case for me.

For me, the gym is so important. I made my 1 hour 20 minute gym session every day during Easter term of fourth year a non-negotiable. It ensured I had a way to de-stress after a long day of work, and I would go at night after I had finished everything for the day. This one thing had compounding effects on my efficiency and recall.

So, my advice would be to dedicate at least an hour, even during exam season, to doing an activity you love, preferably one that involves moving your body, as this is directly correlated with improvements in memory and the release of endorphins.

Final thoughts.

Exam success is easy to overinterpret. Doing very well in SBAs may show broad knowledge, strong recall and good pattern recognition. It does not automatically mean you will be excellent with real patients.

Real patients arrive with several conditions at once. They give incomplete histories. Their investigations conflict. Occasionally, they have not read the relevant PassMed explanation.

The wards and the exam solve different problems. Question banks give systematic coverage. Anki repairs retrieval failures. OSCE practice gives structure. Patients teach variation, judgement and humanity.

Clinical school gives you much more independence than preclinical medicine. The mistake is interpreting that independence as an absence of structure. It means the responsibility for building the structure has quietly moved to you.

And finally, I want to wish everyone the very best of luck, and please do get in touch if you have any questions at all!