Are Your Actions "Next" Enough?

If you're not getting things done, it's not GTD.

Early on, I often found myself looking at an action on my actions list, and thinking, "nah - I'm not going to do that now." It didn't take long for the alarm bells to start ringing.

I started asking myself why I wouldn't do that action now. In most cases, I found that the action wasn't "next" enough. That means I hadn't done the "processing" job properly because I hadn't whittled the job down to the very next physical action.

So now if I find an insufficiently processed action on the list that makes me want to avoid it, I just figure out right then and there what the real next action is, and usually I do feel like doing it straight away. I move the original, not-very-next-action to my projects list, and put the actually-next-action on my actions list, do the action immediately, and cross it off my list. Feels great.

GTD Evangelism

A few months ago I was in bad shape. I had recently taken on a lot more responsibility at work, and found that the main thing I enjoy about work, Java architecture & coding, I didn't have any time left to do. More than that, I couldn't seem to find time to do the other stuff either. And on the rare occasions I found myself with a chunk of spare time to get some work done, I floundered, not knowing which of the hundreds of things I should tackle. This got me really, really stressed out.

Curiously, around the same time I was doing a lot of posting on the Java Posse newsgroup. Evidently I had no time to do any work, but I managed to make time for answering questions on a Java forum! Dick Wall, the guy who runs the Java Posse podcast, is also a fairly senior dude in his company. This made me wonder, how the hell does he find time to put so much work into the podcast, as well as do his job, and have a home life?!

I put this question to him, and his response included a reference to David Allen's GTD (Getting Things Done) system. I had a look at the website and although I was very sceptical I was also desperate, so I bought the book from Amazon, which arrived a couple of days later.

I started reading, and, as expected, it's very American-rah-rah which I suppose is to be expected. But, as I said I was desperate, so I kept going and pretty soon got very excited. It was clear from the first couple of chapters that this was going to be the answer to my problems - or at least, it had the best chance to be.

I read the whole thing in about a day and a half, then headed off to OfficeWorks. The book recommends a lot of specific stuff you should get, like an electronic label maker. I didn't see how that could be important (I do now), but I didn't want there to be any reason the system wouldn't work for me, so I just took everything literally.

My out-of-work life was a mess, to be sure, but it was my work situation that was causing me 95% of the stress, so that's where I went to work implementing the system.

The results were incredible. Within a week, I was feeling a LOT better. After 2 weeks, I had completely organised absolutely everything at work into the system, plus everything I could think of that I wanted to do with my team in the future. It was an awesome feeling - racking my brain, I could not for the life of me think of anything I hadn't covered. What I had in front of me was a beautifully organised filing system, lists of current and future projects, lists of things I needed other people to do, and best of all, a complete list of immediately doable things that would all contribute to the progress of my work. Now I would know exactly what to do when I had a chunk of time at my desk.

The effect on my stress was like magic. Since starting GTD I've been sleeping better, I feel generally positive and more energetic. Even more amazing is the effect it had on my team. The improvement is palpable.

I've been using GTD for 3 months now, and I've made many improvements to my system in that time. No doubt I will make more as I get better at it. I might use this blog to document those improvements as I go, to help people to whom I've been evangelising GTD. (I bought 4 copies of the book to hand out as Xmas presents!) I've also been watching and asking questions on the GTD forums on David Allen's website, mostly for clarification of various concepts presented in the book.

There are various software tools and add-ons out there for implementing GTD, and I looked into them, but the beauty of the system is that it is incredibly simple, and built of things that all of us already do (albeit incorrectly) to organise ourselves. So I've found the built-in features of my email applications (Outlook and Gmail) to be sufficient, although I have invested a lot of energy in getting those settings just right. I also have gone extremely low-tech for the non-digital parts of the system - for example, I now take a simple memo pad and pen to meetings.

I really think this has changed my life, and saved my career. It was clear to me already that I wasn't even coping with my current level of responsibilities, so there was no way I could take on more. And there are lots of non-work things in my life that haven't been progressing, which I feel now I can finally get moving on.

Gushing enough?

 

6 Tips for Java Threads

A while back I replied to a message on the Java Posse newsgroup entitled "Threads are EVIL". The poster was having trouble with Java threads, so in addition to recommending Java Thread Programming and Java Concurrency in Practice, I summarised the basics in the following tips.

#1 - Know what each of your threads does, and which threads can be inside which methods
...You can use asserts to check the names of executing threads in sensitive methods.

#2 - Know which variables are accessed by multiple threads, and which lock guards them
...Brian Goetz recommends annotating/commenting your variables to describe how they are guarded. But the best way to simplify this job is to avoid variables - use immutable classes wherever you can. (They're automatically threadsafe, very fast, and easy to code.)

#3 - Remember it's not enough to synchronize the writes to a shared variable
...You also have to synchronize the reads with the same lock.

#4 - Don't be afraid of the synchronized keyword
...It is NOT evil. Do be afraid however of large stacks of code inside a synchronized block/method. If you find one, take out the bits that don't need to be synchronized and/or split it up into smaller synchronized blocks.

#5 - Avoid nesting locks (ie. synchronized within synchronized)
...Try to think of another way to do it. (There are ways to get away with it, but you're asking for trouble later down the road.)

#6 - Keep it SIMPLE
...Don't do with 2 threads what you can do with 1. (Unless you get a measurable performance improvement by parallel processing CPU-intensive or IO-blocking code.)