I didn't switch from medicine to software engineering. I started both at the same time and eventually had to choose one.
In my second year at the University of Ibadan medical school, I started taking elective courses in computer science. The problem-solving appealed to me in a way I hadn't expected. I enrolled in Harvard's CS50 online, then taught myself React, Node.js, and the modern web stack. By the time I was midway through third year, I had joined a team at Asuqu and shipped my first production software.
From that point on, I was dual-tracking. Full-time medical school during the day, full-time remote software engineering in the evenings and weekends. I did this for over two years, through clinical rotations, exams, and the relentless schedule of a Nigerian medical programme. People ask how. The honest answer is that I didn't sleep much, and I was young enough that it didn't catch up with me immediately.
I get asked about this path constantly. People want to know if the medical background helps with software. If I regret medicine. If the degree was a waste. The answers are yes, no, and no.
What dual-tracking actually looked like
Medical school in Nigeria is not something you coast through. The University of Ibadan's MBBS programme is six years of dense coursework, clinical rotations, and high-stakes examinations. Fitting a full-time remote engineering job around that schedule required a level of discipline I didn't know I had until I was forced to develop it.
I would finish ward rounds or a lecture, go back to my room, and start writing code. I took calls during breaks between clinical sessions. I shipped features on weekends between exam prep sessions. The overlap was constant and exhausting, but it also meant that by the time I graduated with my MBBS, I wasn't a fresh developer looking for my first job. I was already an experienced engineer with years of production code behind me.
The hardest part wasn't the workload. It was context-switching between two completely different modes of thinking. Clinical reasoning and software debugging use similar mental muscles, but the emotional registers are different. Going from a patient interaction to a code review requires a reset that I never fully mastered. I just got faster at it.
What transferred in unexpected ways
Debugging as differential diagnosis
In medicine, you start with symptoms and work toward a diagnosis through systematic elimination. You list possible causes ordered by likelihood and severity. You run tests to narrow the list. You don't guess, and you don't treat without a diagnosis unless the patient is unstable.
I didn't realize I was applying the same process to debugging until a colleague pointed out that my approach was unusually systematic. Most developers I worked with tried fixes semi-randomly: change a variable, restart the server, clear the cache. The clinical training made me incapable of treating without diagnosing. I needed to understand why something was broken before I could fix it.
Documentation habits
Medical documentation has legal weight. If you didn't document it, it didn't happen. Sloppy notes can result in malpractice suits. I carried this into engineering from the start. My pull request descriptions are detailed. My commit messages explain reasoning. My code comments explain non-obvious trade-offs.
This wasn't a habit I developed as an engineer. It was a habit I brought from the wards and never dropped.
Comfort with ambiguity and high stakes
Medicine trained me to make decisions with incomplete information. You rarely have a complete picture. The patient can't always tell you what's wrong. Test results take time. Sometimes you have to act before the labs come back.
Engineering has less ambiguity than medicine, but more than most engineers acknowledge. Requirements are incomplete. User behaviour is unpredictable. Systems interact in undocumented ways. The ability to make reasonable decisions with incomplete information transferred directly, and I was using it in both domains simultaneously.
Working under pressure
A hospital shift teaches teamwork under pressure in a way no standup meeting ever will. When things go wrong clinically, the team coordinates instantly without a retrospective or planning session. You learn to communicate clearly, trust colleagues, delegate, and escalate at the right time.
In engineering, this shows up most during incidents. Production outages, security issues, data integrity problems. The structure of incident response — triage, stabilize, diagnose, fix, document — maps almost perfectly to emergency medicine protocols. I was learning both at the same time, and each reinforced the other.
The year of overlap after graduation
After graduating with my MBBS, I practised medicine for about a year while continuing to work eight hours a day as a software engineer. The schedule was brutal: hospital shifts followed by engineering work, or engineering work followed by night shifts. I was doing both at a professional level, and neither was getting my full attention.
The decision to leave medicine wasn't dramatic. It was practical. I was already earning more as an engineer. The software work was more intellectually stimulating to me. And I couldn't sustain the dual workload indefinitely without the quality of both suffering. So I chose.
How the career has developed
The medical background has become an asset rather than a curiosity. I work in healthcare technology now. Understanding clinical workflows, knowing what nurses and doctors actually need rather than what a product manager guesses they need, knowing the regulatory constraints — these things make me more effective than a pure engineer in this domain.
People ask if the medical degree was a waste. Six years of training for a profession I practised for one year seems like a poor return on paper. But the degree didn't just teach me medicine. It taught me how to think under pressure, document rigorously, and solve problems systematically. And I was applying those skills to software engineering the entire time I was earning it.
The degree wasn't a waste. It was concurrent training for two kinds of practice, and eventually I chose one.
I'm a junior engineer from a non-CS background and this is the most honest account of that transition I've read. The imposter syndrome part in particular. Thank you for writing it plainly.
The differential diagnosis to debugging parallel is something I've felt but never put into words properly. Sharing this with some medic friends who are considering making the switch.
Did you find it useful to keep the medical registration active while transitioning? I'm two years into medicine and thinking about whether to pursue the same path.