Two thoughts on Deciding What to Do Next

It's easy to get stuck in between tasks, trying to determine what is the best thing to do next. This leads to an excess of planning and strategizing, and not enough doing. I had two anti-procrastination thoughts today about the Doing phase of the Getting Things Done methodology.

1. You don't get better at making decisions by thinking or planning, only by doing. It sounds counter-intuitive, but sometimes you can't tell what the best choice is in advance. Only when you choose something and actually do it, can you see the results and use them as feedback to make better choices later.

2. If you're stalled because you don't want to choose "wrong", think about this: if it's in your system as an action item, it's not wrong.  You've already processed the item and decided what it means for you, what the next action is, and put that action on your calendar or an action list.  So if you can't decide what to pick, pick anything at all, rather than continuing to stew.  Anything on your list will move some priority forward, and will provide feedback on what to choose next. Plus, once you're in motion, it's easier to stay in motion and pick the next action... and the next one after that.

New GTD folder - @Watching

I've been using David Allen's Getting Things Done method (GTD) to organize my time for over a year now.  I have a fairly typical set of "@" folders in my Outlook mailbox, such as:

@Action - things to be done as soon as possible, but not on a specific day
@Reading <listname> - things to read when I have time (several of these, one for each mailing list I'm on)
@Someday - ideas for Someday/Maybe
@Waiting - things on hold while I'm waiting for a response from someone

I also have many folders with no "@" on them, which are my project support materials and reference. When I'm assigned a task, I create a folder for its correspondence. But I was having trouble with emails that didn't fall into any assigned task -- typically things that I've been copied on but have no immediate action. However, I want to keep a closer eye on them than burying them among my reference folders, because they may turn into an assignment quickly.

So I added the folder @Watching. I create a subfolder for each topic, and track the email traffic to these subfolders as it arrives. Now, by expanding @Watching, I see a list of topics I'm tracking. If nothing happens or the task is assigned to someone else, I can delete the folder and its contents easily. If the task is assigned to me, I can just drag it up out of @Watching so that it becomes a regular reference folder.

So far, I'm liking this refinement. But of course, I will keep evaluating it as I go.

Interesting Daylight Saving Time Problem

I was teaching an Oracle Database Administration class last week and ran into an interesting problem involving the change to Daylight Saving Time  (you did know that it's Daylight Saving, not Daylight Savings, right?)

For this class, we usually install just the base version of Oracle Database 10gR2 (10.2.0.1.0), because we're on a private network behind a firewall and we don't cover how to upgrade and patch Oracle until the advanced class. And then we show Enterprise Manager Database Control.

Except that this week, it wouldn't come up. We got Java errors, and the home page said that the status of the database instance couldn't be determined. When we tried to start the DB Console service (this is on Windows), it said it was already running; but when we tried to shut it down, it said it wasn't running. Very weird.

In doing a web search for the Java messages (Google is my friend), time and again we were advised to check how our time zone was set. That seemed odd; you wouldn't think that would matter. But it does: the EM agent checks to see that its time zone is (a) valid, and (b) configured is the same as the server.

Enter Daylight Saving Time. In 2007, the US and Canada changed the start date of Daylight Savings Time to be in mid-March (March 11 that year) instead of the first Sunday in April as it had been. This required patching Oracle products with a new timezone file, so they could properly detect the change. (The document ID on My Oracle Support is 359145.1).  This year, we changed to DST on Sunday, March 14.

The class was held the week of March 29, and the unpatched 10.2.0.1 software still thought we should be on Standard Time until April 4. So the EM agent wouldn't start. Had we done the class a week later, or three weeks earlier, this wouldn't have been a problem; and in fact we have done this class many times since 2007 and never hit this issue because the timing wasn't JUST right.

So we did an unscheduled lab to download 10.2.0.4 patchset and apply it, and EM came right up.

Stuff like this underscores the importance of patching your databases, even in a training environment!

There's something to learn from a training perspective here too. We often think that if things go wrong, our students will lose faith in us and think we don't know what we're talking about. But in this case, I was able to model the proper response a DBA should take: stay calm, research the issue, test. I've had students comment in the past when things went wrong that seeing how to resolve such issues was an unexpected bonus of the class. This class felt the same, they enjoyed the "detour" and the problem solving.