The best algorithm for interruptions I know is the one that computers use: the journaling filesystem [0].
The way it works is simple. When you want to do a disk operation, first, you write down in a special place (called a journal) what you are going to do, at a high level. "I'm going to delete this directory and all its files." Then, you go through the steps of actually doing that. Finally, you record in your journal that's what you did.
Now when power is interrupted during a disk operation you simply look at the journal and you can complete any operations that were in-flight at the time of the interruption. For example if the journal says "Delete X folder" and you see it still exists, now you can pick up where you left off.
The application to interruptible programming is straightforward. I have an actual paper journal and I will in a few words explain a task to the journal before I begin. Often I end up with a hierarchical journal, like
get the unit tests to pass
the unit test doesn't pass on OSX because postgres isn't running
start postgres
the unit test doesn't pass on Linux because the postgres credentials are wrong
refactor postgres credentials to work right on both platforms
one particular Linux machine still doesn't work
Is it 32-bit related?
No
Are we using the same compiler on that machine?
The overhead of recording this information is microscopic, and the benefit of returning from every interruption to a page or so of context is awesome. It's almost better to be interrupted now, because I come back to a clearly defined problem, as opposed to starting on "blank slate" items with no direction.
As a side benefit, I now write really good commit messages, because I just write what my journal says I did. Which is quite a lot more detail than it was when I was trying to remember things after the fact.
This works for me, I used to have a file I would create with 'to do', 'doing', and 'done' values on each of the steps. But someone here on HN pointed out that I could use Trello for that which I tried, and it was absolutely the best for this. Make a board,, think of the top few things that have to be done, pick one, move it over to 'doing' it will spawn a few more things, start picking them off one by one. And putting them into the done column.
To whomever suggested that, I owe you a beer or something :-)
If you want to use a journaling system digitally, I would suggest starting a slack chatroom for just yourself. It's designed for teams, but using the simple chatroom interface for just yourself works surprisingly well.
I do this very thing on a legal pad, except before "get the unit tests to pass", I add a box that I can check off because checking boxes makes me feel nice.
One advantage of physical paper for the journal is that it doesn't take up screen real-estate or require switching tabs to enter into it. Another advantage is that I don't have to clear it out when I get done with a task. I just turn the page.
I've noticed that moving things around to different parts of your brain helps cognitive functions.
One example of this is rubber ducking [0]; the act of moving a problem from the part of your brain that you use to think about it, out through the part you use to serialize sentences to another person, helps in problem solving.
I have found this works often in my day to day life. I will be get struck at one thing and when I about to drop a mail, and I write the detail explanation about the problem, I get the answer.
And this is the basis of any other lock-free algorithm also (it'll make it easier to hand-off, delegate tasks, let others finish what you started, ...)
The way it works is simple. When you want to do a disk operation, first, you write down in a special place (called a journal) what you are going to do, at a high level. "I'm going to delete this directory and all its files." Then, you go through the steps of actually doing that. Finally, you record in your journal that's what you did.
Now when power is interrupted during a disk operation you simply look at the journal and you can complete any operations that were in-flight at the time of the interruption. For example if the journal says "Delete X folder" and you see it still exists, now you can pick up where you left off.
The application to interruptible programming is straightforward. I have an actual paper journal and I will in a few words explain a task to the journal before I begin. Often I end up with a hierarchical journal, like
The overhead of recording this information is microscopic, and the benefit of returning from every interruption to a page or so of context is awesome. It's almost better to be interrupted now, because I come back to a clearly defined problem, as opposed to starting on "blank slate" items with no direction.As a side benefit, I now write really good commit messages, because I just write what my journal says I did. Which is quite a lot more detail than it was when I was trying to remember things after the fact.
[0] http://en.wikipedia.org/wiki/Journaling_file_system