Tickets are rented. Domains are owned.

A service is the responsibility for a system over time. You own the spec, the data model, the API contract, the test coverage, the deployment, the on-call night when it breaks. You own how it will look to the company in three years, and the documentation that will outlive your tenure. The first service I owned taught me this in the first month: the code was fine. The knowledge of why the code was fine lived in three people's heads, and one of them was leaving.

So this became the chapter where I learned that documentation is not overhead. It is the artifact that makes ownership possible. If I owned a service, I wrote down what it did, why it did it that way, how it could be extended, what would break it. I produced documents the same week I produced the code, and I kept them in sync as the service evolved. By the end of two years I could be handed a tangled legacy service from another team and produce a clear spec, a working refactor, and a deployment plan inside a week. Reliability had become my currency, and it compounds quietly. Teams do not remember your best demo. They remember the quarter nothing went down.

AZcare followed as a contributor role on a healthcare platform, and it set the bar that made the discipline permanent. Healthcare is a domain where mistakes have consequences, so the habits translated directly: schema versioning, audit logs, validation at the API boundary, integration tests that exercised the actual data flow. Production never failed because of code I wrote. That sentence is the bar healthcare quietly enforces, and once you have held it, you do not want to work below it.