I've been thinking about a few related things lately. I wrote Everything in modulation, about the idea of focusing on transitions rather than constancy. I've also written about motivation-driven development, the idea of doing harder things earlier because they require the most motivation. Recently, especially in my last few failures, I've also seen a pattern: things seem to go to pieces easily when I have a lot going on, and when they do it's much harder to keep working on them unless it's in one big burst to catch up.
Putting these all together, I've been starting to ask this question: what changes? Let's say you have an enormous mountain of things to do. Now you finish one thing. What changes? You still have a mountain. Or worse, let's imagine you have some big scary task to do, something that's weighing on your mind and stressing you out, but you also have some little tasks to do first. You do the little tasks. What changes? The big task hasn't gone anywhere, and if anything it's gotten worse, because you're more tired and have less time to do it.
So the first part of this idea to make sure you have meaningful transitions in your work. If you have two different bits of work to do, putting them back-to-back means that the answer to "what changes?" is "I go from working to more working". This is a useful way to think about breaks, not necessarily as an opportunity to recharge or recover from work, but as a chance to make the transition between tasks more meaningful. Of course, it's important to remember that the work-to-break transition has an equal but opposite break-to-work transition afterwards, and that can be dangerous, especially if the task after the break is the harder than the one before it.
Another way of thinking about it is, instead of focusing on work-break transitions, focus on the transitions in your situation that result from doing the work. This is the perhaps obvious idea that you should do the things that make the biggest difference first. If your two tasks are "finish the feature I'm working on in this project" and "have an uncomfortable conversation with the project manager about probably missing a deadline", those are both important things to do. However, although the first one is easier and arguably more productive in absolute terms, the latter results in the bigger change in your situation: you go from having the deadline conversation looming ahead of you to having it behind you.
The other thing is that the idea of "what changes?" is based on your own perception, which means it can also be useful to try to change your focus. If you perceive your work as one giant undifferentiated lump then it's pretty difficult to find meaningful transitions in it. Even if you break it down, it's important to break it down in such a way that the parts are meaningfully different from one another. This is one thing I like about working iteratively in software, each iteration produces a new working version. The answer to "what changes?" is obvious and visible, rather than leaving large gaps where you're not sure if there's any progress at all.
Sometimes it can be just as simple as paying attention to the transitions. If you're not looking for changes, it can sometimes seem like the things you're doing just leave you in the same place. But even small changes can be meaningful. This is the basis for techniques like journalling, self-measurement, and generally setting up useful frames of reference.
But the most important thing is just that the answer to "what changes?" should never be "nothing". The reason is simple: doing nothing is a far more efficient way of changing nothing, and your optimiser won't hesitate to suggest that instead. And, if you really do think nothing will change because of your actions, you have to admit it has a point.