On building things that matter

I got into software because I liked solving puzzles. I stayed because some of the puzzles have patients on the other side of them.

The version that doesn’t ship

Most software I’ve written has invisible failure modes. A bug in a recommendation engine shows the wrong product. A broken analytics pipeline gives you stale numbers. Annoying, fixable, low stakes.

Healthcare software has a different failure profile. A clinical note that gets summarized incorrectly doesn’t just waste a physician’s time — it can affect a care decision. An HL7 message that gets mis-routed might mean a lab result that doesn’t reach the ordering provider. The margin for “good enough” is different.

I don’t say this to be dramatic. Most of the work is still the same — API design, database queries, Dockerfile tweaking, arguing about naming conventions. But the frame is different. It makes you slower in some ways and more careful in most.

What changes when the stakes are real

You write more tests. Not because someone told you to, but because you’ve felt the specific discomfort of deploying to a system where a bug isn’t just a ticket, it’s a phone call.

You document more. Not because documentation is fun, but because the person who maintains this in two years might be making a decision at 11pm and needs to understand what this field means without you being there to explain it.

You push back more on scope creep. “Let’s add a feature that auto-populates medication history from unstructured notes” sounds exciting right up until you think through all the ways it could be confidently wrong.

The part that still surprises me

The physicians and nurses I’ve worked with are good at their jobs in a way that makes me want to be better at mine. They’ve internalized a level of rigor — about uncertainty, about edge cases, about what it means to not know something — that most software engineers never develop because we’ve never had to.

The best thing software can do in this space is get out of the way and handle the boring reliable parts reliably, so the people with actual expertise can focus on the parts that require expertise.

That’s not a very exciting mission statement. But it’s an honest one.