What Working in Healthcare Tech Taught Me About Software

Two and a half years ago, I joined Dedalus to work on healthcare information systems. I had a CS background, some side projects, and the usual mix of ambition and overconfidence that comes with a first engineering job. I thought I knew what writing software meant.

I didn't. Not really.

Software that runs in hospitals is different

Not because the code itself is magical or exotic - it's Java, it's SQL, it's the same primitives you'd find anywhere. What's different is the cost of being wrong.

When you write a feature for a consumer app and there's a bug, someone gets a wrong number on a dashboard or a UI glitch. Annoying, fixable, forgettable. When you write a feature for a clinical system and there's a bug, it could affect a medication record, a diagnostic workflow, or a clinician's ability to access patient history at a critical moment. The stakes are calibrated differently, and that calibration changes how you think.

I became a much more conservative engineer. Not timid - conservative. I learned to ask "what happens when this fails?" before asking "how do I build this?" I learned to be suspicious of my own cleverness. The most elegant solution is not always the most appropriate one when reliability matters more than elegance.

Legacy code is someone's live system

Healthcare systems accumulate age. Our codebase had sections that were older than my career. Some of it was written before modern Java practices existed. Some of it worked through mechanisms nobody fully understood anymore.

Early on, I would look at this code and feel a kind of contempt - why didn't they do it properly? But that contempt faded as I understood the context. The people who wrote it were solving real problems under real constraints. Their code ran reliably for years, processing millions of patient records without incident. Who was I to sneer at that?

What I learned was to approach legacy code with the same curiosity I'd apply to any interesting system. Understand before you change. There is almost always a reason something was done a certain way, even if the reason is no longer obvious. Find the reason before you decide it should be different.

The discipline of traceability

Healthcare software lives under strict regulation. Changes require documentation. Deployments require sign-off. Every bug fix needs a traceable chain from report to root cause to resolution to verification.

I used to find this process slow and bureaucratic. I now think it's one of the most valuable practices I've internalised. The discipline of writing down what you changed, why you changed it, and how you verified it isn't just compliance theatre. It forces a kind of rigor in your own thinking. You can't be vague about what you did if you have to explain it to someone else in writing.

I carry this into personal projects now. Commit messages that explain why, not just what. ADRs for decisions that might be questioned later. The habit costs a little time and repays it many times over.

What I'd tell myself starting out

Don't be in a hurry to change things. Understand the system first, even if - especially if - the code looks confusing or wrong. Ask the people who've worked on it longest what the tricky parts are. They will tell you things no amount of reading the code will reveal.

And take the domain seriously. I spent time learning what clinical assessment scales actually measure, how diagnostic workflows are structured, what different parts of a hospital actually do. That knowledge made me a better engineer on this codebase than any additional framework knowledge would have.

The software is a model of the domain. If you don't understand the domain, you don't fully understand what you're building - or what you might be breaking.

Healthcare tech isn't glamorous. It doesn't make it onto many "hottest companies" lists. But writing software that contributes to clinical care, even indirectly, gives you a sense of consequence that I find genuinely motivating. The stakes being real is not a burden. It's a reason to do the work well.