The work was basically done. That is always the dangerous sentence. The main change worked, the demo looked fine, and the next task was waiting. But the notes were thin, the rollback was not written, and the final check still lived in someone's memory. The visible finish line had arrived before the real finish.
Finishing properly is not glamorous. It is checking the edge case, updating the note, removing the temporary flag, writing the handoff, linking the evidence, and making sure the next person does not have to ask what happened.
This discipline matters because unfinished edges become future interruptions. The code may run, but the team still pays if nobody knows how to verify it, operate it, or explain why a trade-off was made.
I have learned to respect the last ten percent of work. It is where confidence becomes inspectable. A passing test is useful. A passing test plus the reason it matters is better. A deployed feature is useful. A deployed feature plus rollback criteria is calmer.
The temptation is to rush away once the visible problem is solved. That temptation is understandable. Teams have pressure, queues, and deadlines. But moving too quickly can create a trail of almost-finished work that slows everyone later.
Finishing properly also protects pride from becoming performance. The point is not to prove that every detail is perfect. The point is to leave the work in a state where someone else can continue without guessing.
A small closing ritual helps. What changed? How was it verified? What remains risky? What should someone do if it fails? Where is the evidence? These questions turn done from a feeling into a shared state.
The quiet discipline of finishing properly is a form of care. It cares for the next teammate, the future incident, and your own attention tomorrow. The task is not really done when it works once. It is done when the work can stand without you holding it up.