Follow-up To: Reinforcement and Short-Term Rewards as Anti-Akratic
I'm still working on cleaning up my scheduling system for release, like I mentioned in the comments to my last post. However, I managed to forget the end of my college semester, which is taking up a distressing amount of my time. So, although progress is being made, I'm not done quite yet and probably won't be until sometime after my final exams end on the 16th. In the meantime, I'm going to explain my scheduling system and some of the modifications I've made to it.
My system is derived from the Pomodoro Technique. In it, work is separated into individual 25-minute blocks also called "Pomodoros." To ensure that blocks last for the full 25 minutes, they're timed; once the timer has started, the block should not be uninterrupted until the timer runs out. There's a short break between each Pomodoro; after several Pomodoros, there's a longer break.
The biggest benefit I've noticed from using my system is in fixing my problems with task switching. When I was doing something I didn't much like, I used to think about doing something else almost constantly; it usually wasn't long before I stopped working to do something else. The original Pomodoro Method solved this problem by forcing me to wait until the timer had expired to stop working. However, I had another problem with task switching that the original Pomodoro System didn't touch. When I was slacking off, I could sit contented for hours without doing anything else; I found it hard to start working or stop slacking off. That's where my changes came in. These problems are both very similar; in this one, I change tasks too infrequently, where in the other, I changed tasks too often. It stands to reason, then, that they could both be solved the same way: by timing them. So, in my system, everything I do is treated like work is under the Pomodoro System, even slacking off.
That's the biggest change my system makes: everything is a block (or a Pomodoro), and I'm in a block all the time. However, my system is more than just a few rule tweaks. My system is computerized; I use a web application for my block timer, as well as for managing my task list and the various other add-ons my system has. I've also made a number of more subtle decisions that better adapt the system for computerization.
Like in the Pomodoro System, my system times each block of work I do. After the work period ends (usually 25 minutes), my system enters a 5-minute break period. During this break period, I preload my next task into the system so that I can start working as soon as the break ends, without having to futz with the timer. If I forget to preload a task, my system doesn't start anything automatically; I'm just left outside of a block, which I consider to be a failure state that I always try to avoid.
My system also integrates a task list; to start a block, I must choose my task from the list. This also helps to improve my productivity. Because I choose tasks from a list of all my potential activities, it's easier to find and select tasks with higher activation energy, instead of falling back on cached procrastination. Forcing me to select a task from a list also makes me explicitly consider what I ought to be doing with my time.
A web application is nice, but there are a lot of things about it that, on its own, make it a bit less useful than the traditional timer. It doesn't ring, for instance, and I have to open it up every time I want to check how much time I have left. So, I built an application that runs on another computer on my desk that handles all of those things. It rings a digital gong when the current timer ends. It shows me whether I'm in a break, in a task, or if my task has expired by changing the color of the screen. It displays in text the current task, some information about it, and how much time is left on the timer. Right now, this is a fairly bare-bones terminal application; one of the things I'm working on in my current revision is making it look a bit nicer.
Of course, my extrinsic motivator from my previous article is tied into this system as well. Simply put, it rewards me with candy for keeping on track with my schedule. The rules it follows are more precisely explained in its own article. I'm rewriting the rules, however; expect a new article about them in a few weeks.
Even the best scheduling system in the world would be of no use if I couldn't bring myself to follow it. That's what my browser plugin is for. When I don't have a block timer active, or if I'm trying to access a non-productive web site during a productive block, my browser plugin will block the site and tell me to go start a block. I can still override the plugin, but the plugin requires me to wait 10 seconds before I get the option. Since most of my procrastination time is spent on the Internet, the plugin is an effective way of reminding me to turn the system back on.
Since my goal is to keep the system on at all times, it's a bit problematic that many of real-world tasks don't divide neatly into Pomodoro-sized chunks. These are things like eating dinner, walking the dog, or sleeping. In order to track them, my system has a category of "real-world" tasks which run for an indefinite amount of time. However, such a task would seem open to abuse; in order to prevent that, my browser plugin blocks my access to the Internet during them, just as if I weren't in a block at all.
My original plans for the system included things like reports on time usage and a system to help me calibrate my expectations for the amount of time a task is likely to take. However, I've yet to implement any of these, and honestly I'm still not sure what the best way to implement these would be. Any interesting suggestions would be appreciated; I hope to write an article about building these systems sometime soon.