Check out this really great post by Ryan Cooper on why “later means never”. Come back here if you like, but at least go read Ryan’s piece.

This is something I am always working on. From the perspective of putting this into practice, I have found two things helpful:

1. Keep a running “done” list on a pad of paper next to your keyboard. Jot things down that come up as you work that need to be completed before this task is done. Before commit, that list should be empty. I specifically recommend using paper over whiteboard or text file for this for several reasons: a) it’s a physical reminder to do something (both when writing and when finishing), b) you can keep the paper in reach and take it with you (often not the case for a whiteboard), c) paper is free form which is ideal for jotting notes, diagrams or whatever necessary to jog your brain. I also find it helpful to keep a list of things to fix (say, copy-paste duplication, hard-coded file path strings, whatever) that I happen to see while working on a task. Generally, I like to finish the task I’m on, then empty that list of to-be-fixed items afterwards. If they are too big to do immediately, they need to turn into tasks or bugs that can be prioritized and fixed. In some cases, if the to-fix things are isolated from my main change, I may even make a quick digression to fix them first.

A bit of an aside: If you store lists like these digitally, I recommend having a well-known file for each such list and actually creating a shortcut for it in your tool bar or wherever you launch your common apps from. That makes it always visible, and assuming it consumes some constant physical part of your screen, burns it into visual memory where to find it. The key is that there should be no delay or hesitation to jot down something you see without losing the flow of what you&#8217;re doing. </li> 

  * For me, the last and final gate is always commit. Before I commit a set of changes to source control, I review every diff in the change set and mentally ask whether this change I&#8217;ve made is really and truly done. Is it tested? Is it documented? Is the change even necessary or was it something I just tried out? It also serves as a final code review of all my changes, which is somehow very helpful when seen out of your editor context in a diff compare. I can&#8217;t say how many times this final review showed me something I did not expect or had forgotten. I&#8217;ve come to view it as the most critical step in my own personal process. </ol> 

Hope these ideas are useful to somebody.