“I don’t have enough context” is useful for about five minutes.
A lot of the work I’ve done started with me not really knowing what I was doing.
Not in the reckless sense. More in the very normal sense of being dropped into a problem where I understood maybe 30% of what was going on. I didn’t know the domain well enough. I hadn’t used the technology before. I didn’t know why the current process worked the way it did. Sometimes I didn’t even know what questions I should be asking.
Earlier, that used to make me uncomfortable. I thought I was supposed to understand the whole thing before I started building. Learn the system, read the docs, understand the edge cases, then write the code. It sounds sensible, but in practice I rarely had that luxury. Most real problems did not arrive as clean tickets with all the context attached. They showed up as something vague like “this process is too manual,” “this keeps breaking,” or “can we automate this?”
Working in insurance made that obvious very quickly.
I didn’t join knowing much about health insurance beyond the surface level. Then suddenly I was dealing with claims, reimbursements, eligibility, payments, plan rules, carriers, TPAs, provider workflows, and all the weird little exceptions that only make sense after you have seen them a few times. A problem that sounded simple from the outside would turn out to have three systems, two spreadsheets, four people, a third party, and some undocumented rule that apparently everyone knew except me.
At first, I kept thinking I needed to understand everything before I could make a good decision. Eventually I realized that I was learning more by following one real case than I was by trying to understand the entire domain in advance.
So that became the pattern. Pick one case. Follow it from start to finish. Ask why that step exists. Look at the data. Talk to the person doing the work. Build something small. Get it wrong. Fix the mental model. Build again.
A lot of context only showed up after I started.
The same thing happened with technology. I’ve had projects where the thing I needed to use was something I had never worked with before. A new API, a framework, browser automation, payment infrastructure, mobile, AI, whatever the problem needed. I used to think there was some point where I had to “know” the technology before I was qualified to use it. I don’t think that anymore.
Usually I just need to know enough to take the next step.
Read the docs. Build the smallest version. See what breaks. Read the docs again, now with a much better idea of what I’m actually looking for. That second pass is almost always more useful than the first. Before building, everything in the documentation looks equally important. After something breaks, suddenly one paragraph matters a lot more than the other fifty.
I’ve also noticed that people explain things differently once you have something concrete in front of them. Asking someone, “How does this process work?” usually gets you a decent answer. Showing them a rough version and asking, “Is this what happens?” gets you a much better one. They’ll point at something and say, “No, this only happens in this case,” or “You’re missing the step where we do this,” or “That field actually comes from somewhere else.”
That is usually where the useful context is hiding.
Because of that, I don’t really see prototyping as just a way to build faster anymore. It is also how I learn what the problem actually is. A prototype makes assumptions visible. It gives people something to disagree with. It tells you what the API actually does instead of what you assumed it did. It shows you which part of a process matters and which part was just described badly.
That doesn’t mean “just start coding” is always good advice. Some mistakes are cheap. Some are not. If money, security, privacy, compliance, or irreversible actions are involved, I want more certainty before moving. But most problems are not binary choices between “understand everything first” and “blindly ship.” There is a middle ground where you can move carefully and learn as you go.
That is probably the part I’ve become most comfortable with: not knowing.
Now, when I get a problem I don’t understand, I don’t immediately worry about whether I have enough context to solve it. I try to figure out how to get the next piece of context. Who knows this process better than me? Can I see a real example? What does the current workflow look like? What data do we have? What is the smallest thing I can test? What would be expensive to get wrong?
Usually that is enough to get started.
Then one answer leads to another question. One implementation exposes a bad assumption. One conversation changes the shape of the problem. Slowly, the thing that felt completely foreign starts to make sense.
And once it makes sense, it is very easy to forget that it ever didn’t.
That is the part I find interesting. When someone understands a system deeply, their answers often sound obvious. But the obviousness came later. It came from seeing enough cases, making enough mistakes, asking enough dumb questions, and spending enough time inside the problem.
I still say, “I don’t have enough context.” Sometimes that is exactly the right thing to say.
I just don’t think it is a reason to stop anymore.
It usually means I need to go get it.
Thanks for reading.
More about Animesh
