When I complete something that I'm working on, rather than calling it a day, I usually start on the next thing. Not in the hopes of finishing a great deal more work, usually it is just to get a feel for what is in store next.
Nothing is more fulfilling than working in a state of flow for a few hours — or more, as the time seems to pass so quickly — to complete a proof of concept, a new feature, or some much needed refactoring. All of the tests are passing and the work has been committed to source control. It feels complete, tidy, and satisfying. It is a logical point to call it a day. But almost always when I'm in this situation, I start on the next thing. Half of my brain thinks: good job, pack up, it's late, you're hungry. The other half is eager to get a taste for what to work on next, and, for me, this temptation is almost always irresistible.
I never really thought much about this behaviour — I'm not even sure I was conscious of it — until I was at the CppCon 2014 conference and Kate Gregory mentioned as part of a panel discussion that she never stops at a sensible stopping point, as a means of being more productive. She does this when writing and when programming. It made me reflect on why I do this. I think there are two reasons. One is so that I start mulling over problems in the background and, two, so that I can get back into a state of flow more easily when I resume my work.
We've all had the experience of being stumped by a difficult problem, only to walk away from it for a while and come back to it with a satisfying solution that wasn't obvious at the time. I think I like to start on the next challenge so that I start working on the problem, even if it is just in the subconscious. It at least allows me to mull over the problem on my trip home and prepare myself for tackling this next challenge. A means of reorienting and not having to spend all of that spin-up time at work. If you keep watching that panel discussion, Bjarne Stroustrup mentions that when he is writing, he finds the first day is a struggle. He spends the first day "filling up the cache" and it is only on the second day that he actually gets the bulk of his work done. I can relate to this. I find starting on my next task lets me fill the cache passively, as I go about other things.
I also return to a state of flow more quickly. Flow is a term coined by the psychologist Mihaly Csikszentmihalyi to describe the state of being fully immersed in a task with a feeling of energized focus. Getting into a state of flow can take 15 to 30 minutes, and each time you are pulled out of a state of flow, it can take equally long to reestablish it. People are particularly sensitive to noise and interruption during this immersion period. Refer to the software management classic Peopleware for an excellent discussion of the challenges of establishing flow in the workplace.
By leaving my work at a place where it is easy for me to pick up, I think it allows me to get back into a state of flow more readily. When I start working on the problem again, I know exactly what my first task is. For writing, Kate uses the example of leaving your work with "for example". The equivalent for me when programming is implementing a class and stubbing out the first unit test, but not completing the unit tests. Or partially refactoring some code and letting the compiler remind me the next day the places that I still need to revisit. The next day I have well-defined tasks that quickly reestablish my state of flow. Once back in a state of flow, it is easier to stay there. Interestingly, I rarely have a problem picking up where I left off, even if a significant amount of time has passed since I started on the task.
This technique may not be for everyone. In fact, it may not appeal to some people because it can mean, in some sense, that you are always thinking about your work. But perhaps give this technique a try and see if it helps you be more productive.