I've worked in two industries as a software developer — telecom and healthcare. Both involve large-scale distributed systems, event-driven architecture, real-time data pipelines. The technical problems are genuinely similar.
But the way I think about writing software is completely different now. And I think healthcare did that to me.
***In Telecom, the Stakes Were Scale*
In Telecom I was building Kafka pipelines that handled hundreds of millions of events a day. The engineering problems were real and interesting — latency, fault tolerance, schema evolution, consumer lag. When something went wrong, throughput dropped, dashboards went red, and the on-call engineer had a bad night.
That's stressful. But the worst case scenario of most failures was: some events got delayed, some metrics were stale, some retry queues backed up. You fixed it, you wrote a post-mortem, you moved on.
The users of the system — the telecom customers — mostly never knew anything had happened.
In Healthcare, the Stakes Are Different
My first week at my Organisation now, I was shown around the clinical operations. I saw the actual documents my code would be processing — patient referrals, discharge summaries, operation notes. Real documents, with real patient names, real diagnoses, real medication lists.
And I realised something that sounds obvious but hadn't fully landed before: the output of my code connects to a real person's care.
A wrong patient URN doesn't just fail a unit test. It means a document gets filed against the wrong patient record. In the best case someone notices and fixes it manually. In a worse case, a clinician makes a decision based on incomplete or incorrect information.
I'm not saying this to be dramatic. I'm saying it because it genuinely changed how I write code.
Three Things That Changed
1. I stopped tolerating silent failures
In a lot of systems, silent failures are acceptable. A job fails, logs an error, moves on. You catch it in the morning during the daily review.
In healthcare I became almost allergic to this pattern. If something goes wrong I want to know immediately and I want to know exactly what went wrong. Not a generic exception. Not a null pointer that bubbles up three layers. The specific thing that failed, why it failed, and what state the data was left in.
This led me to design the OCR service I built at Kingsbridge with explicit failure modes. If the system can't confidently extract a patient URN, it doesn't guess — it flags the document for manual review. That's a deliberate design decision, not a fallback. The uncertainty is surfaced, not hidden.
I've taken this thinking back into every system I build now. Silent failures are technical debt you pay in trust.
2. I started thinking about the person at the end of the pipeline
In telecom I thought about throughput, latency, and uptime. These are the right things to think about.
In healthcare I started asking a different question before designing any feature: who is going to use this, and what will they do with the output?
For the OCR service the answer was: a clinical admin team member, who will take this Excel output and use it to match documents to patient records. That person is not a developer. They don't know what OCR is. They don't care about my architecture. They care about whether the output is correct and whether the errors are clearly labelled so they can handle the exceptions without calling IT.
That shift in perspective — from "does the system work" to "does the system work for this specific person in this specific context" — is something I now apply everywhere.
3. I push back more
This one surprised me.
I always thought I was reasonably good at asking questions about requirements. But healthcare gave me a much lower tolerance for building things I wasn't sure about.
The cost of building the wrong thing in a clinical context is high. Not just wasted engineering time — potentially wrong data in production, potentially a process that introduces errors that are hard to find later. So I started pushing back in planning meetings more. Not aggressively, but persistently. "What happens if the document doesn't have a label in the expected position?" "What should the system do if the confidence score is below threshold?" "Who is responsible for reviewing the exceptions?"
These questions feel slower in the moment. They make planning meetings longer. But they make the actual software much more reliable because you've thought through the edge cases before you've written a single line of code.
The Unexpected Benefit
Something I didn't expect: writing software this way is more satisfying.
When I shipped the OCR service and it went into production, I knew exactly what it did, what it didn't do, how it failed, and who was responsible for each failure mode. I knew the clinical staff using it had been involved in testing it on real documents. I knew the exception handling matched their actual workflow.
That's a different feeling from shipping something that works in the demo but has a bunch of edge cases you're not sure about.
I think most developers want to write software that matters. Healthcare has a way of making that very concrete, very quickly. The feedback loop between what you build and whether it actually helps someone is short and visible.
That's a privilege, honestly.
***What I'd Tell Developers Thinking About Healthcare Tech*
It's not as inaccessible as it looks. You don't need a medical background. You need the same things you need in any domain: curiosity about the actual problem, willingness to ask questions, and the discipline to handle edge cases properly.
What you get in return is a clarity of purpose that's harder to find in other domains. The work matters in a way that's tangible. And that tends to make you a better engineer.
Top comments (0)