The Life and Times of Gordon Worley.

Generational Data Storage Technology Trust

Sat, 1 Aug 2009 11:11:37 -0400

I grew up using computers, so I trust them to store my data. My laptop contains most of the information that is important to me: if I were to lose it and the backup of it that I keep, I would lose nearly everything I have ever created, from programs and papers to love notes and pictures. But I don't really worry about this: a lifetime of not losing my data has led me to trust the combination of original and backup in digital form.

But not all people feel this way, especially those who came to computers later in their lives, because they sometimes exhibit a distrust of the computer's ability to reliably store their data for later retrieval. Anything that's really important to them they prefer to write down or print out, just in case the computer (and the backup, if they keep one) fail. Plus, they might argue, what if the power goes out or the software that reads my files stops working? Then I can't get my data, and it's just too important to trust to something like that.

As the Internet has grown more powerful, many people are storing their data in the cloud. Millions of people have all their e-mail online, all their pictures uploaded to Facebook, and all their important documents in Google Docs (or simply as attachments to messages in their gmail account). And many, if not most, of these people don't keep local copies or backups of their data because they trust the Internet services they use to safely store their data for later retrieval. Why wouldn't they? It's worked reliably so far.

But I find I just can't do this. I need to have local copies of e-mail, documents, pictures, and everything else on my computer because I don't trust Internet services to always be able to serve my data to me. What if a service goes out of business? What if the local network, or even the entire Internet, goes down? Then I can't get my data, and it's just too important to trust to something like that.

Hmm, sounds like I might be guilty of the sins of the previous generation, only updated slightly to reflect changes in the technology. Maybe my data really is safe in the cloud, but I'm not sure I'll ever be totally comfortable with it. I'm tempted to say that storing data in the cloud versus storing data locally on your computer is different from comparing computer to paper storage, and I can think of many reasons why, but I can't put away the feeling that I'm succumbing to the same bias that keeps my parents generation printing things out. Thoughts?

Free iPhone Apps

Tue, 23 Jun 2009 12:42:52 -0400

Not to make plugs for my apps a regular thing here, but I just wanted to let everyone know about a cool new site giving away iPhone apps for free, including one of mine! The site is AppGiveaway and the idea is simple: developers offer free copies of their apps, you enter a drawing, and a few winners are picked at random. I'm testing it out with Genius Proof, and depending on how it goes I might put some other apps up on it.

iPhone Apps

Tue, 9 Jun 2009 21:21:20 -0400

I haven't been posting about it on the blog, but I just wanted to take a moment to point out what I've been working on lately. I have now released four iPhone applications, with three currently on sale, and my wife has helped with the last couple of them by providing content and many good suggestions. In lieu of real content, I encourage you to check out what I've been up to over on the Software page. And if any of them strike your fancy, don't forget to write a review, good or bad.

Thanks.

Less Wrong is More Right

Wed, 13 May 2009 17:35:07 -0400

Cheesy title, I know. This is just a short post to encourage you to go check out Less Wrong, a blog about various things of interest to me, including rationality, probability theory, productivity techniques, and the winning way. I've posted a few articles there, and one even got promoted (that's a technical term, in this case). If you've enjoyed my posts about Getting Things Done or have an interest in even a tangent of a topic I've mentioned above, I recommend that you at least take a look.

Even if that's not your cup of tea, I'd also like to suggest that you check out Overcoming Bias. It's similar in content, but more heavily moderated and more focused on economics, especially now that it's pretty much just Robin Hanson posting. Overcoming Bias is, in many ways, the ancestor of Less Wrong.

Simplifying GTD: Tools to Use

Wed, 22 Apr 2009 17:05:12 -0400

In the last several posts I've discussed how I've learned to better take advantage of GTD. To finish up, I want to talk about the tools I use in my system and the tools I'd like to have/may need to create.

The heart of my system is OmniFocus. This is a very well designed GTD action management program that was clearly written by people who use it themselves to get things done and don't have time to waste working through a ridged workflow or crossing every t and dotting every i. You can very quickly create actions, organize them, search them, and edit them without spending a lot of time in the application. It has flexible display options, which I consider a plus, because I can make my next actions list look just how I like:

I like to color my actions by past due (red), due soon (green), and due later (blue), but there are no red ones to show because I already renegotiated all the incomplete past due actions for the day. Many people prefer to split their actions up into sections under group headers, or at least you'd think that given the general design of GTD software, but I find it harder to get much done when things are organized in that way.

Not everything is great about OmniFocus. It is missing several things I'd like it to have, including a general tagging system that permits assigning multiple tags and a filtering system that supports boolean sentences of search parameters. As it stands, I can only filter by "or" over contexts and "and" over other properties (due date, start date, flagged, etc.). Additionally, actions can only be assigned to one context and one project, so I use contexts to try to denote the tools that I need and project to denote the category of the action (i.e. is it related to work, family, etc.), which I find extremely limiting. Plus the only way to access OmniFocus away from the computer is by an iPhone/iPod Touch app, but since I don't have one it means I'm tied to my laptop when there would otherwise be no reason to carry it.

OmniFocus does talk to Mail.app, though, so I have the following set up. From my phone I can send e-mail via the text messaging interface (if a contact has no phone number, it will automatically send the text message to the e-mail address associated with that through my carrier's text-to-e-mail gateway), allowing me to put stuff in my inbox wherever I am. I also carry a Pocket Mod, a letter sized sheet of paper folded to create a disposable notebook with 8 pages, which I sometimes use to write down stuff if it can't be easily typed in a text message or if I'm going to use it before I get back to my computer.

I use iCal to track the "landscape" of events occurring at fixed times. I sync this with Google Calendar so that I can have access to it on the go, although because of OmniFocus I don't find I use this feature often. I unfortunately don't use iCal as much as I'd like to because at work we use GroupWise, so I need to do most of my calendaring there, and since there's no good gateway between GroupWise and iCal, I'm stuck.

So, if OmniFocus is so nice, why don't I just go on using it? Well, part of it is likely my desire to tinker with the tools I use to turn them into exactly what I need, but I think it's also because OmniFocus comes very close to what I want by falls just shy. Since it's closed source, I can't do much to customize it, so I'm left with, what are to me, some major limitations. I won't bore you with all the details here, but I've written up a design document of how my ideal action management software would work. The elevator description of it is "vi meets a web application that supports flexible but highly automated operations on GTD actions with support for offline use". If I ever have the time, I'll start an open source project to create it. In the mean time, if someone wants to undertake such a project, feel free to ask me for the details and start it yourself: for fun, profit, or both!

Simplifying GTD: Actionless Projects

Sun, 5 Apr 2009 19:15:55 -0400

As I discussed in the first article in this series, I don't collect actions in projects in my GTD system. And I don't collect actions in projects because there's no need to if you're using a computerized system. If you still use a pencil and paper GTD system, not everything I say here will apply to you, because for you projects are still a good way to collect actions that depend on one another.

The traditional purpose of a project in GTD is to provide a higher level of organization than actions, which includes grouping actions together that are working towards the goal of a project. And certainly each of your actions should be working towards some goal, be it a project you want to accomplish or a higher life goal (if an action is not working towards some goal, why did you bother to write it down in your system so that you'd remember to do it?). But when you're down to the business of deciding what to do next, your goals don't matter. Nor, for the purposes of expressing action dependencies, do your goals matter. Actions are in the business of getting things done; projects and goals are in the business of deciding what actions to create to get done later.

Given this split, it's certainly clear that you don't need to keep actions attached to projects, but why should we choose not to attach actions to projects? Like much of my GTD advice, it comes down to practicality. Keeping actions tied to projects requires an extra step in the processing phase (you have to explicitly decide what project to attach it to) and past using that assignment to track action dependencies and relationships, it doesn't serve a purpose again. And if you want to track dependencies, you might as well do that directly rather than through the veil of projects.

Some might object that they use projects to help them decide what to do next. They say that knowing what project an action is working towards helps them prioritize. But to me, this is a symptom of poor due date negotiation: if you have to decide between two actions which one will get done today and which one will have to wait, then either they both must be done today because you set their due dates for today, or you can renegotiate one of the actions' due dates. And in the process of renegotiation you'll have to consider why it is that you need to get this action done, naturally leading you back to the project towards which it's working. So again, no real need to keep the action in a project.

I admit, though, that this article is probably the hardest of all the ones I've written in this series to swallow. I doubt many people reading this will go right out and stop tracking actions in projects, because part of the purpose of any GTD system is to get things off your mind, and if you're worried about whether or not a project will be completed because you didn't assign any actions to it, then you need to be assigning actions to projects. So consider this penultimate article in the series an idea to ruminate on: you too may find one day that you no longer feel the need to assign actions to projects.

Next time, we'll wrap up with a look at how I get things done and the tools I use, plus a look at where I'd like to see the tools headed.

Simplifying GTD: Practical Use of Contexts

Mon, 2 Mar 2009 09:02:26 -0500

Having conquered due dates, let's turn out attention to contexts. For GTDers, context is a somewhat vague term referring to a where and what you need to complete an action. Common examples of contexts include phone, home, boss, wife, and office. Had GTD been developed only in the last few years, contexts might have been called tags. And while such a flexible tool can be useful to have, it also invites the opportunity for trouble, such as the temptation to spend more time getting the contexts "just right" in your system than necessary.

I find it's best to think of an action's context as conditions that, unless met, you cannot do the action. For example, if you need to write a blog entry, you may need to have met the "internet connection" and "computer" conditions. Then, when you go to your list of available actions to pick something to do, you will only consider writing a blog entry if both those conditions are met. Implementing contexts effectively in this way requires computer assistance, though. If you use a paper system, or even a computer system that doesn't easily allow you to assign multiple contexts and filter by them on-the-fly, then your contexts will need to remain vague in order for the system to remain usable. Remember, the whole point here is to get things done.

If you have the necessary computerized system, I find that contexts/conditions break down into just a few categories: location, tools, and time. That is to say, where I need to be, what I need to have, and what time it needs to be in order to perform an action. In many cases one or two of these may not be specified. For example, to write this blog entry, my only requirement is to be at the computer; it doesn't matter where I am or what time of day it is in order to write it. But if I need to call my gram, I need to have my phone and it needs to be between 10 and 19 o'clock. And if I want to make sandwiches to take for lunch for the week, I need to be at home and have sandwich making supplies. Unfortunately, I have yet to find a system that supports this model well and has all of the other features I want in a GTD system.

Thus, if you find yourself using a paper system or a computerized system incapable of the features described above, a reasonable compromise to to assign context by the primary condition that needs to be met. From the examples above, my gram gets a time context because I almost always have my phone, and making sandwiches gets a home context, since I usually address the supply issue during a grocery shopping action, making location the determining factor. This workable solution does have the downside of sometimes showing you actions you can't accomplish because you haven't met all of the conditions, but overall it does a reasonable job of winnowing down the list of all available actions to make the decision of what to do easier.

Next time we'll take a look at how to use projects if you don't use them to collect actions. Then we'll wrap up the series by looking at the tools I use and consider possible directions for the development of GTD software.

Simplifying GTD: Negotiating and Renegotiating Due Dates

Fri, 20 Feb 2009 07:08:00 -0500

As promised, here is the second post in my series on Getting Things Done. This time I'm going to talk about due dates, specifically negotiating and renegotiating them with yourself.

First, just what is a due date? It may seem obvious, but many people don't use them in a practical way, and I think a lot of this stems from a lack of discussion about what a due date should mean: they seem like such obvious things that there must not be anything to say. But the reality is that due dates deserve much more attention.

So, what is a due date? With regard to actions, a due dates should be treated as the date by which you would like to accomplish the action. This is not the date by which an overdue action produces a proverbial fire, or the date by which you think you should have the action done, but the date you are comfortable with trying to accomplish the action by. If you have five overdue actions, this should not mean that you have five fires or five things to feel guilty about, but five actions that need to be reviewed within your GTD system. Treating due dates any other way leads to stress and system distrust.

As an example, suppose I have a report to write. This project consists of several dependent actions, so for the sake of demonstration let's suppose that they are

set up the document's format
pull the file with the data for the report
write the intro/summary section
write the background section
write the data section
write the analysis section
write the conclusion
proof read
turn in the report

with each action dependent on the previous one. Suppose that today is the 1st of the month and the report is due on the 15th. Now for each action I need to set a due date. I know I can get the document set up in just 10 minutes, so I set the due date for that as today. Pulling the file doesn't require much thought, but there's a lot of stuff in the filing cabinet and I don't like digging through there, so I set the due date to tomorrow so that I can put it off until I have the mental energy for it. I decide to give myself two days to write each of the sections, so their due dates will be on days 4, 6, 8, 10, and 12, respectively. Finally, I give myself two more days for proof reading, setting its due date to the 14th, so I can turn in the report on the 15th.

With each action I'm trying to decide how much time I want to give myself to get around to doing that action, knowing that I may complete some of them early and others late, and also keeping in mind that I am not creating any actions that I believe will exceed the maximum time I am willing to work on a single action. If at this point I was uncomfortable with or felt stressed by any of the due dates, I'd look at them again to see if I can find the source of the trouble (single actions that are really multiple, too much stuff due on a particular day, etc.) and correct it (break the action apart, renegotiate some due dates, etc.).

This example demonstrates what I like to call negotiating due dates. You are trying to make an agreement with your future self about when you will try to accomplish something by, but also realizing that a due date may slip, in which case your future self will have to renegotiate the due date. To some people this is blaspheme: if you missed the due date you're in trouble. But as I said, you need to set due dates so that when some of them are missed you can address the situation.

Renegotiating a due date comes comes in several forms. At the most basic level, you are simply setting a new date by which you would like to complete an action. For example, if I didn't water the plants today, I'll just bump the action to tomorrow. Not all due dates are so easily renegotiated, though. Returning to the report example, suppose that I get busy and don't complete the analysis section on time. In addition to changing this action's due date, I may also need to update when I plan to complete the conclusion and proof reading so that I can complete the project without generating a lot of extra stress from being "behind" schedule.

The most difficult sort of renegotiation comes when missing a due date has consequences beyond delaying project completion. In the report example, let's say that you get sick and haven't written the conclusion or done the proof reading by the 15th. Further, for the sake of argument, let's assume that you could not have someone else complete these actions for you. Then when the 15th comes and you have no completed report to turn in, rather than immediately trying to put out the fire and get the report done, ignoring everything else you have to do, take a step back and see what you need to do now in order to complete the report. Is it possible to turn it in later? If so, what do you have to do to achieve this? Then create new actions to help you turn in the report late. In my case, let's say those actions are

e-mail boss to inform that report is not done and ask if I can have two more days to complete it
when boss replies, set due dates appropriately on remaining actions

In the mean time you can work on the report's actions, work on other actions, or do whatever is the best thing for you to be doing right now. Even if your boss e-mails you back to say that you had better not leave the building until the report is done, you can still use this to renegotiate your due dates, especially the due dates you're going to miss because you're putting out a fire.

So when you're in the trenches, getting things done, here's what you should take away.

Set action due dates to when you would like to get the actions done.
Renegotiate past due actions.
Get down to "overdue zero" by renegotiating or moving overdue actions back to your inbox for later processing.

As a final, bonus note, I want to mention start dates. Start dates are pretty easy to set, but you should take advantage of them. Some people just ignore them, saying they want to get started on everything as soon as possible, but this quickly leads to a situation where you have too many actions available to work on. For recurring actions, start dates usually denote when the soonest you can think about doing the action again (I'm not going to pay the phone bill for next month the day after I paid it for this month). For other actions, use them to give yourself enough time to do an action without it stepping on the toes of others. I usually expect that I'll procrastinate on a typical action for two days, but if I know I'm not going to want to do the action I set the start date further out so that I see the action for more days, giving me more time to get up to doing it.

As you can tell, I take due dates pretty seriously, but only because I became much more productive once I realized their proper use. Next time I'll continue the series by looking at either projects or contexts.

Simplifying GTD: Less Planning, More Action

Fri, 13 Feb 2009 06:19:10 -0500

I've been using the Getting Things Done philosophy for a few years now, and the longer I use it the more I understand the subtleties of personal productivity management. In what I hope will become a "regular" series on my blog, I want to discuss the lessons I've learned so that I may help others get more out of GTD.

Many people, when coming to GTD, want to bring with them complex systems that track lots of metadata: time estimates, priorities, milestones, subsubprojects, and more. I think that this is largely due to a feeling that if only we could capture a little more information about what we have to do it would be easier to do it, but also because you would want to track all of these things if you took the union of every personal productivity and project management system for the last 50 years. Combined with the tendency of software developers, even of GTD software, to implement more features over time, you get a situation where you could spend more time tinkering with your system than actually using it to get stuff done.

The solution, of course, is to simplify and cut out whatever you don't actually need to know in order to be productive. The trouble comes in deciding what things to cut, or the way I like to think of it, what things you actually need. In my experience, the minimum necessary information you need to record for each action is:

description
start date (or lead time)
due date
(optional) repetition rule
context
dependencies

The description should describe clearly what you need to do. The start date is the soonest you are willing to consider the action doable. The due date is when the action is due, be that a personal deadline or an externally enforced one (I plan to write more about due dates in a later post). The repetition rule is used only for recurring tasks, but I say it's optional because not everyone finds automated recurrence desirable, instead choosing to create actions to tell them to create the next recurrence of an action. Context is a bigger subject that I want to discuss in detail, but for now I'll just say it's what you need and where you need to be in order for an action to be doable. And dependencies should describe which actions become doable after other actions are complete.

Notice some of the things I don't record. Most GTDers will think I'm crazy for not assigning actions to a project. But, really, what is a project? To my mind they serve two purposes. One is to help you see the proverbial forest from the trees, and the other is to track the relationship between actions. If your GTD system is paper based, projects are one of the few ways to track action dependencies in an efficient manner, but if your system is on the computer, a named project isn't really necessary. All you need is a link that says "you can't do this action until this other action is done". Not all computerized GTD systems make this possible, but I consider it an essential feature and I plan to go into more detail in another article about the whys and hows of living out from under the shadows of projects.

Of note to nonGTDers, I don't record priorities. The reason is simple: priorities take too much effort to decide on and keep consistent and provide too little added value. Unless you are stressed out about not recording priorities, don't, because it's more important to get something done than the most important thing done and what's most important often shifts too rapidly to be accurately recorded anyway. I also don't like to record time estimates. If an action takes more than 15 or 30 minutes (whatever is your largest discrete time chunk that you can stay focused on a single task), either split up the action into multiple actions that are within those time chunks or create "work on ... for X minutes" that only commit you to spending time working on something that has no clear parts you can break out.

By my count I've planned at least three future posts in this series. In the next one I'll either talk about use of contexts, negotiating and renegotiating due dates, or the proper role of projects. Later, I also plan to discuss effective user interfaces for computerized GTD systems and tell you about the tools I use.

Birthday '08

Tue, 11 Nov 2008 17:15:50 -0500

Most years I would forget my birthday if other people didn't remind me of it, but since getting married I'm assured not to let it slip by unnoticed. My wife, Sarah, always makes a big deal of birthdays, which as she says are "as important as Christmas" in her family. I'm not yet fully acclimated to this, but she's doing her best to speed along the process.

My birthday was last Tuesday, election day this year in the US, so we didn't want to do anything that night given that voter turnout was expected to be high and roads and restaurants would be busy. Instead, since I've been begging to go to nearly anything dinosaur related lately, we went to the T-Rex Cafe at Downtown Disney. Sarah let me build my own birthdaysaurus (courtesy of Build-A-Bear and shown above), eat amid a frenzy of ferocious (viz. animatronic) dinos. Dinner was unfortunately only so-so and the dining room was too loud, but afterwards we made up for it by cracking open a geode and getting a few little dinos for my birthday cake on Wednesday.

Despite the food, if you can't tell from the photo, I had a blast. I've always been interested in prehistoric animals and Sarah encourages my interest by letting me make it into a hobby and obsession. She really knows how to show the birthday boy that he's loved.