Got "Getting Things Done" (GTD) by David Allen" over the holidays, because it was mentioned by Tom Limoncelli in "Time Management for System Administrators".

I've gone through most of it, and would still recommend that techies go for "Time Management for System Administrators". It's short, funny and in language you can understand and for situations that you can relate to. It covers most of the important things GTD does. It also provides a good practical system that's easy to understand and apply.

GTD often uses lots of jargon terminology and CEO like situations which doesn't make it enjoyable to read for me. If you do not already have a system it would be hard to get started. In trying to address as large an audience as possible, it provides too many options. I skipped most of the early parts as you would already have it in place if you have read Tom Limoncelli's book or if you're a tech user. For example, GTD tells you replicate your workspace at home or on the go. Time Management for Sysadmins, that's a given. What self respecting geek, goes somewhere without their notebook and mobile Internet access? Or doesn't have home server(s)"

In keeping with the CEO theme, it also touches upon managing and tracking multiple large scale projects. This is the part of the book that was valuable to me. It includes dealing with management at a group and organisational level and not just personal. I was not well prepared for this towards the tail end of IOSN. Reading through it, I guess I stumbled upon the solutions myself the hard way. I'm heading towards this situation again soon, and this time would like to be better prepared.

GTD is recommended reading if you've already got a system in place, and you may want to check out some other ideas which may be applicable to you. Also recommended if you need to manage multiple complicated projects, which involves multiple teams. Otherwise for techies, Time Management for System Administration may be all that you need.

Fasting month of Ramadhan has done a lot of good for me in a practical sense. For one, I've rearranged my sleeping schedule to start the day at 5am. I kept trying last month, but it didn't seem to stick. Now I can get up at that time without needing an alarm clock. I love the Nike Awake ad. Someone told me they didn't get it. Basically at the end it's the alarm buzzer going off after showing what all the different people do to start the day at the crack of dawn before you wake up. Switch sahur with a proper large breakfast to start the day and it's all good.

Fasting is also tiring. This makes me depend even more on my organizer to keep things in focus. If you're tired you let one thing slip, then the next.. and to catch up you get tired, let more things slip and the cycle repeats. True enough, I got a lot of overdue things done and also started new projects.

I've written before about prioritising tasks. In that article I didn't use urgency yet. While I'm aware of what priority items are each day, they were not attended to efficiently. A lot of small simple tasks were therefore building up, when they should be cleared first thing in the morning since they take up so little time. This resulted in a lot of priority 1's and a lot of priority 2's left undone and building up as they were never attended to even though they were trivial.

Now I also assign urgency (A,B,C,D) to tasks, on which should be done first, even to priority 2's. Now I have a second level of prioritization that allows me to more efficiently deal with tasks building up. I use them as:

A - quick task, just do it now if it's priority 1, do it quickly first for priority 2 if you find an idle moment

B - this is going to take a bit more time, probably will need to be bumped up as priority 1 and dealt with properly

I don't use C or D, too fine grained for me. For these, I leave it as priority 3 tasks.

FOSS developers have a huge advantage over proprietary software developers in that you have access to the development of the tools and libraries you use. This includes bugs, project direction and insight from the main developers.

I'm getting back into development working with Plone and Zope3. So here's how I go about it, and like most others, there isn't anybody around me working with it.

I don't want to simply know how to use the tools, and libraries to write basic applications. You should be able to do that with the docs and tutorials provided by most projects. I want to understand best practices and the design of them. At first, to at least understand what the direction of the next version will be, and then to be able to contribute towards development and direction of the next version. Even if it's just at bug reporting and feedback on proposals.

Why is this important? Most serious projects need to be maintained and improved. If you're using frameworks and libraries, then if your project is not in line with upstream, you'll be losing more and more of the benefits of collaborative development of FOSS. You may end up duplicating work, or not be able to take advantage of the new features in new versions. If you don't even file bugs, then if nobody faces the problems, maintenance of them is all on you.

You also want to tune in, because there is a lot of tips, links and other experiences that other more experience developers share. You can then learn more about what tools they use, and their development environments.

So how do I start?

http://www.palm.com/us/software/chatteremail/

This application turns your Treo/Centro into a Blackberry with support for push IMAP. I find this feature rather scary though.

What is useful for me though is the summary folders feature, that allows you to select several folders from multiple accounts and display it in one virtual inbox grouped by day, sorted by time and color coded based on your settings.

This helps me with quickly getting an overview of emails, and then schedule and organise emails that have tasks. Then while there, quickly file or delete emails.

Related: Email Manages You!

This concept has been rehashed and changed into multiple buzzwords and agile this and that. At it's core though it's a basic concept of how to prioritize tasks.

At whatever level you are, when you're doing tasks or projects, the first thing you should do is identify (or try to find) the major risks first. What they are depends on the nature of your job. Here are some:

• Sysadmin - server needs backup mechanism
• Event manager - booking venue and invites
• Developer - key features required by stake holders, and then go by features that may take long development cycles
• Project manager - issues that will block key deliverables or cost overruns

and so on..

Everyone has to bear some amount of personal responsibility, even if you're junior staff. A common scenario is that you're given a project to finish at a set date, but before that date you're assigned random tasks so that you never actually get to finish it.

What you need to do is be aware of that initial responsibility, and when an adhoc task is assigned to you (that's life), you need to always weigh the priority against your key tasks to complete your project. Always be aware of that, and when assigned random tasks, negotiate and make aware of it to your manager. Most managers will understand and appreciate this, and help you prioritize, either by extending deadlines, or delaying the adhoc task, or reassigning it to somebody else. They'll also recognize your abilities to manage and deliver on projects, which means you're next in line for promotion.

For managers, what's obvious to you, may have been gained through years of experience. So it's important to share management skills with your staff. If you're a growing company, this will be a good base for expansion, as your junior staff start becoming junior managers.

Some more tips here: http://kaeru.inigo-tech.com/articles/time-management/managing-tasks/