DEV Community: Monika Sonnad Math

What I Wish I Knew Before Starting a Career in Tech as a Woman

Monika Sonnad Math — Wed, 08 Jul 2026 16:06:12 +0000

I have been a software developer for four years now. I have worked across two countries, two industries, and several teams. I have had good experiences and uncomfortable ones. I have learned things the hard way that I wish someone had told me before I started.

This is not a post about how difficult it is to be a woman in tech. It is a post about what I actually wish I had known. Some of it is practical. Some of it is about mindset. All of it is true.

You will have to prove yourself more than once

Not just when you join a new company. Not just when you join a new team. Repeatedly, in small ways, in the same rooms with the same people. This surprised me. I thought once I had demonstrated what I could do, that would be it.

It is not it. You keep demonstrating. And eventually you realise that the solution is not to prove yourself harder. It is to stop needing the validation in order to do good work. That shift is genuinely freeing, even if it takes time to get there.

Your instincts about the code are probably right

Early in my career I would second guess myself constantly. I would notice something that felt wrong in a design or a piece of code, wonder if I was missing something, and stay quiet. Then someone else would raise the same concern and it would turn out I had been right.

This happened enough times that I started paying attention. My instincts were not wrong. I was just not trusting them.

Now when something feels off I say so. I frame it as a question if I am not certain. But I say it. The number of times that has turned out to be useful versus the number of times I have been wrong is not even close.

The room being uncomfortable does not mean you are in the wrong room

I spent a lot of time early in my career interpreting discomfort as a signal that I did not belong somewhere. A meeting where I was the only woman. A technical discussion where I felt out of my depth. A networking event where I did not know anyone.

The discomfort was real. But it was not evidence of anything except that I was somewhere new and unfamiliar. Those are almost always the rooms worth being in.

Find your people early

I found communities of other women in tech later than I should have. When I finally did, through GirlCode and Reed Women in Technology, I realised how much energy I had been spending that I did not need to spend. Energy on wondering if my experience was normal. Energy on navigating things alone that other people had already figured out.

Having a community does not solve the structural problems. But it does mean you are not solving them alone. That matters more than I expected.

You do not have to be the most technical person in the room

I used to think that the way to be taken seriously was to know more than everyone else. To have the answer before anyone asked the question. To never be caught not knowing something.

That is exhausting and also not how good engineering works. Good engineering is collaborative. The best engineers I have worked with are the ones who ask clear questions, listen carefully, and change their minds when they get better information. None of that requires knowing everything.

Share your work

I kept quiet about things I was building and learning for longer than I should have. I thought I needed to be more experienced before I had anything worth sharing. I thought sharing would look like showing off.

It does not. Sharing what you are learning is how you connect with other people who are learning the same things. It is how you find out you are not alone in the problems you are solving. It is also, honestly, how you get better at what you do, because articulating something forces you to actually understand it.

I started writing and open sourcing projects this year and I wish I had started earlier.

The career is long

This sounds obvious but I did not really believe it early on. I was in a hurry. I wanted to be further along than I was. I compared myself to people at different stages and felt behind.

Four years in, I can see how much has changed. Not just in what I know but in how I think. The engineers I respect most did not get there quickly. They got there consistently. Showing up, learning, building things, making mistakes, doing it again.

You have more time than you think. Use it to build things properly rather than fast.

What Working in Healthcare Tech Taught Me About Writing Software That Actually Matters

Monika Sonnad Math — Fri, 12 Jun 2026 15:51:33 +0000

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.

I Work in Healthcare Tech. Here's Why I Built a RAG Tool for Clinical Documents.

Monika Sonnad Math — Wed, 03 Jun 2026 10:24:19 +0000

I didn't set out to build a RAG application. I set out to solve an annoying problem I kept watching happen.
I work as a senior software developer in healthcare technology in Belfast. A big part of that job is understanding what actually slows them down, and figuring out where software can help. Not what's technically impressive what's genuinely useful.
One thing I kept noticing: a lot of time gets spent navigating documents. Not reading them carefully and thoughtfully — just navigating. Ctrl+F for a patient name. Scrolling to find a medication dosage. Hunting for a follow-up instruction buried in paragraph four of page seven of a discharge summary.
It sounds small. Multiply it by every clinical document, every working day, and it adds up fast.
When I started thinking about RAG as a solution, the first thing I did was slow down and think about what "accuracy" means in a clinical setting — because it means something different here than it does in most software contexts.

The Problem With Most AI Demonstrations in Healthcare
Most AI demos in healthcare go like this: upload a document, ask a question, get a fluent confident answer. It looks impressive. The problem is that fluent and confident doesn't mean accurate. Language models are optimised to produce coherent text. Left to their own devices they'll fill gaps, make inferences, and sometimes just invent things — in a way that reads exactly like a real answer.
In most contexts that's an acceptable tradeoff. In a clinical context it isn't. A patient's discharge medications, their follow-up appointments, their documented allergies — these things need to come from the actual document, not from a model's best guess based on what usually appears in documents like this.
So before I wrote a single line of code I made two decisions:

Temperature 0. No creativity. Deterministic responses only. The model either finds the answer in the document or it says it doesn't know.
Explicit system prompt. The model is told directly: answer only from the provided context. If the answer isn't there, say so clearly. Do not guess.
These aren't complicated decisions. But they're the right ones for this use case, and I see a lot of healthcare AI demos where nobody made them.

How RAG Actually Works (Without the Hype)
RAG stands for Retrieval-Augmented Generation. The idea is straightforward:
Instead of asking a language model a question and hoping it knows the answer from training, you first retrieve relevant sections from your actual documents, then ask the model to answer based only on what you retrieved.
The pipeline looks like this:
Document (PDF)
↓
Extract text
↓
Split into chunks
↓
Embed each chunk as a vector
↓
Store in a vector database

↓ (at query time)

Question
↓
Embed the question as a vector
↓
Find the most similar chunks (semantic search)
↓
Send those chunks + question to the LLM
↓
Get an answer grounded in the document
The key word is grounded. The LLM doesn't know what's in your documents from training — it only knows what you retrieved and passed to it. If the answer isn't in the retrieved chunks, a well-instructed model will tell you that.

Building It: The Decisions That Mattered
Chunking strategy
How you split documents into chunks matters more than most tutorials acknowledge. Too small and you lose context — a medication dosage split from its drug name is useless. Too large and retrieval gets imprecise.
I landed on 500-character chunks with 50-character overlap. The overlap is important — it means the boundary between two chunks always has context from both sides, so you don't lose meaning at the split point.
splitter = RecursiveCharacterTextSplitter(
chunk_size=500,
chunk_overlap=50,
separators=["\n\n", "\n", ". ", " ", ""],
)
The separator hierarchy matters too. We try to split at paragraph boundaries first, then sentence boundaries, then spaces. Splitting mid-sentence is a last resort.
Embedding model
I used OpenAI's text-embedding-3-small. It's fast, cheap, and good enough for document retrieval. For production clinical systems handling complex medical terminology you'd want to evaluate domain-specific embeddings — but for a general-purpose tool this works well.
The system prompt
This is where clinical RAG lives or dies:
system_prompt = (
"You are a helpful assistant that answers questions about clinical documents. "
"Answer only from the provided context. If the answer is not in the context, "
"say so clearly — do not guess or make up information. "
"In a clinical setting, accuracy matters more than completeness."
)
That last sentence — accuracy matters more than completeness — is doing a lot of work. It gives the model permission to say "I don't know" rather than producing a plausible-sounding answer. In my testing, including it made a real difference to the rate of hallucinations on edge cases.

What I Learned Building This
The messy document problem is real. Most RAG tutorials use clean, well-structured PDFs. Clinical documents are not clean or well-structured. Scanned discharge summaries with inconsistent formatting, referral letters with abbreviations that differ between hospitals, guidelines with tables that don't chunk cleanly — all of these degrade retrieval quality. I've started thinking about pre-processing pipelines to handle this better and may add that to the project.
Confidence matters. I added a simple confidence indicator based on how many relevant chunks were retrieved. It's a rough heuristic — more retrieved chunks suggests a more answerable question — but it gives users a signal about how much to trust the response. In a clinical context, knowing when to verify against the source document is as important as the answer itself.
The UI needs to be dead simple. Clinical staff are not developers. If the interface requires any technical knowledge to operate it won't get used. The Streamlit app has three interactions: upload a file, type a question, read the answer. That's it.

The Code
The project is open source on GitHub: github.com/Monika-Sonnadmath/clinical-rag
It has a Python API for developers who want to embed it in their own pipelines, and a Streamlit web app for anyone who just wants to use it directly.
pip install -r requirements.txt
export OPENAI_API_KEY=sk-...
streamlit run app.py
Upload a PDF, ask a question, get an answer. That's the whole thing.

What's Next
A few things I want to add:
• Local LLM support via Ollama — so it works without an API key and keeps documents entirely on-premises. For clinical use cases, data leaving the building is a concern.
• Multi-document querying — ask a question across a folder of documents at once
• Better pre-processing — handling scanned documents with variable quality, which is very much a solved problem in OCR but needs connecting to the retrieval pipeline
If you work in healthcare tech and have thoughts on what would make this more useful, I'd genuinely like to hear from you.