On the inner loop, and progress being a vector sum: one thing I find crucial is knowing where I have to go. That translates to two mantra: rush to the finish line, then rebuild it if needed.
When embarking on a project I know roughly what stages are needed. Maybe three dependencies, one more to bring them together, one more to deliver a subsequent result, and one outer one to present the whole code. Example: a web scraper to get weather data, a thermometer polling daemon, a database to store the two, a scheduler to run the first two and store it in the database, and a module to perform high level queries on past data and forecast trends for the future.
It’s really easy to deep dive on any one of those components. It’s not until I get to the final one that I realize how little I really know about problem. I’ll explore it a little, then work on something else for a week, then come back and know exactly how to retackle the problem from start to finish. It’s the revisiting that gives me insight into what to do, and it was the rush to build the prototype that gave me the raw materials needed to have that insight.
All of this requires at least one whole day of concentration, then three half days of tinkering, then a final week of rewriting and polishing and responding to code review.
So much of this process is subject to external forces that impact my productivity. I am grateful to this article for solidifying them in writing.