The boundary kept moving.
The boundary of a software problem keeps moving outward. What first looks finished at the feature edge can become a question about the system, then the product, then the person trying to understand and trust it.
A perspective note, not a résumé.What I used to count as finished
I used to count a software problem as finished when the code produced the expected result and the feature behaved in its immediate path. That definition was useful, but it had a small horizon. It left the surrounding promises—capacity, timing, failure, and the next person in the path—outside the frame.
The first widening
At Microsoft, I worked in the problem area of allocating GPUs to guest virtual machines across clusters. The work made the boundary harder to ignore: resource allocation was also about capacity, consistency, latency, reliability, and failure modes. A local answer had to keep making sense in the larger system around it.
A question I keep carryingBefore: Does this feature work?
After: What has to remain true for it to keep working?
Then the product became part of correctness
In early-stage product work, the boundary widened again. Responsibilities moved across architecture, data and document workflows, AI-enabled work, privacy, interfaces, and user trust. The question was no longer only whether a technical path completed. It was also whether the whole path helped a person understand what was happening and what they could do next.
That changed how I think about trust: not as a measured outcome I can claim here, but as a design responsibility I should account for while making the product.
What I ask first now
I start by locating the promises around the request. Who or what depends on this staying true? Where can the experience become unclear? Which constraints will surface later if I leave them unnamed? The questions are deliberately broad at first; the implementation can become specific after the boundary is visible.
The question still open
Breadth helps me see more of the path, but depth still earns the right to change it. I am still working out how to balance both—and how to make that balance useful in collaboration, where no one person should pretend to hold the whole system alone.