On Sleep

The wave of interest in recent times of so-called polyphasic sleep has become very pervasive. I’ll have to admit that even I took keen interest in it around the time I started this blog. I’ve read countless articles on sleep, and now, I’ve come to the following conclusion: the problem is not figuring out the bare minimum of hours of sleep you need each day; rather, the real problem is figuring out how you can be more active/productive while awake. If you cannot confidently say “I spend all of my awake-time doing productive things”, then there is no point of “hacking” your day so that you sleep less hours; what’s the point of buying more books if you cannot finish reading the ones you have already?

I think most people initially accept the proposition that if you sleep less, you’ll get more done. The common one-liner you’ll read in most articles goes something along the lines of “even if you shave off just 1 hour off of your usual sleeping cycle, this meager saving will net you X extra years of life!“

This kind of thinking is plain wrong. Unless you are narcoleptic, sleeping too much is NOT the problem. The real problem is figuring out what you are going to do while you are awake. You can sleep 6 hours, 4, hours, 2 hours even, in a single day. Nobody cares. The only thing you should care about is how you spend your time.

Now, I do understand that for some people, spending more hours out of bed will guarantee more productivity. But this is only true if the pending task is very simple and does not require much decision-making. Unfortunately (or fortunately, rather), very few people in the modern world today share the same working career as child laborers did at the dawn of the Industrial Age. Unless a supervisor directs all of your attention to predefined goals from the minute you wake up to the minute you go to bed, so that you are reduced to a drone working for the Hive, sleeping less does NOT mean increased productivity.

Besides, there are far more important problems to tackle than “hacking” your brain to get less sleep:

• How can I spend more quality time with my family?
• How can I stay healthy?
• How can I improve my relationship with my partner?
• How can I improve my mind?
• How can I conquer my fears?
• How can I stop procrastinating?
• …etc.

None of these important questions involve sleep as a material part of the solution. Sleep, my friend, is irrelevant. All of the questions above instead have the goal of increasing the quality of life. So don’t fool yourself into thinking that sleeping less is an integral part of self-improvement. Sleep, like everything else in life that can be objectively quantified, must be taken in moderation.

Unified Configuration File Setup Across Multiple Machines – Revisited

My last post discussed how to get your config files, known as “dotfiles,” synchronized across multiple machines using a rudimentary makefile and git. I said that I hoped of achieving the “one folder for all config files” dream. I have achieved it, and it is pretty simple. Also, I will discuss how to handle files with passwords in them, and some other thoughts on this setup.

Keep track of system files, too

Essentially, my last post left out all but the system configuration files, such as /etc/fstab and the like. The /etc folder is owned by root, as well as the /boot folder. My first approach was to simply replace all such files with more symlinks, which would point to files owned by the normal user of the system. This approach had its drawbacks: (1) not all system files are symlinkable (e.g., /etc/sudoers is particularly security-conscious), and (2) the idea of deleting system files and replacing them with symlinks, on its face, sounded like I was setting myself up for a big grand screw-up.

So I thought: “Well, since system files are seldom ever edited anyway, why not just back them up periodically?” And that’s what I did instead. Now my makefile, as discussed in the previous post, has a section like this:

# copy contents of system files to keep track of them
syscopy:
ifeq ('$(HOSTNAME)','exelion')
	cat /boot/grub/menu.lst >       /home/shinobu/syscfg/sys/boot-grub-menu.lst-exelion
	cat /etc/X11/xorg.conf >        /home/shinobu/syscfg/sys/etc-X11-xorg.conf-exelion
	cat /etc/fstab >                /home/shinobu/syscfg/sys/etc-fstab-exelion
	cat /etc/hosts >                /home/shinobu/syscfg/sys/etc-hosts-exelion
	cat /etc/inittab >              /home/shinobu/syscfg/sys/etc-inittab-exelion
	cat /etc/makepkg.conf >         /home/shinobu/syscfg/sys/etc-makepkg.conf-exelion
	cat /etc/rc.conf >              /home/shinobu/syscfg/sys/etc-rc.conf-exelion
	cat /etc/rc.local >             /home/shinobu/syscfg/sys/etc-rc.local-exelion
	cat /etc/rc.local.shutdown >    /home/shinobu/syscfg/sys/etc-rc.local.shutdown-exelion
	cat /etc/yaourtrc >             /home/shinobu/syscfg/sys/etc-yaourtrc-exelion
	cat /etc/sudoers >              /home/shinobu/syscfg/sys/etc-sudoers-exelion # requires superuser privileges to read!
else
	cat /boot/grub/menu.lst >       /home/shinobu2/syscfg/sys/boot-grub-menu.lst-luxion
	cat /etc/X11/xorg.conf >        /home/shinobu2/syscfg/sys/etc-X11-xorg.conf-luxion
	cat /etc/fstab >                /home/shinobu2/syscfg/sys/etc-fstab-luxion
	cat /etc/hosts >                /home/shinobu2/syscfg/sys/etc-hosts-luxion
	cat /etc/inittab >              /home/shinobu2/syscfg/sys/etc-inittab-luxion
	cat /etc/makepkg.conf >         /home/shinobu2/syscfg/sys/etc-makepkg.conf-luxion
	cat /etc/network.d/luxion-wired > /home/shinobu2/syscfg/sys/etc-network.d-luxion-wired
	cat /etc/network.d/luxion-wireless-home-nopassword > /home/shinobu2/syscfg/sys/etc-network.d-luxion-wireless-home-nopassword
	cat /etc/rc.conf >              /home/shinobu2/syscfg/sys/etc-rc.conf-luxion
	cat /etc/rc.local >             /home/shinobu2/syscfg/sys/etc-rc.local-luxion
	cat /etc/rc.local.shutdown >    /home/shinobu2/syscfg/sys/etc-rc.local.shutdown-luxion
	cat /etc/yaourtrc >             /home/shinobu2/syscfg/sys/etc-yaourtrc-luxion
	cat /etc/sudoers >              /home/shinobu2/syscfg/sys/etc-sudoers-luxion
endif

I have in my /etc/rc.local the command “make -f /path/to/the/above/makefile -B syscopy“. So every time my system boots up, all of the config files are copied into their backup-equivalents in the syscfg/sys folder. Since git tracks changes in the syscfg folder, only changes in the config files are detected and tracked as changes (i.e., git doesn’t track changes in file modification times, which is a good thing here for our purposes — otherwise git would be saying that every time we boot up all of our system files have changed!). So now all of my system config files are tracked passively (by merely reading off them). Of course, if I manually edit a system file, I can still call make -B syscopy myself manually, and then run git diff in the syscfg folder to track those changes, and then git commit to solidify those changes into the git history.

For config files with passwords in them

DO NOT EVER PUT CONFIG FILES WITH PASSWORDS INTO YOUR TRACKED DOTFILES FOLDER! Not only does this mean that your password, in plain text, is tracked by git, but that should you ever change your password, git will notice the changes and track them as well! This will give anyone who gets access to your git repo a complete, timestamped history of your passwords for your applications (like icecast, irssi, etc.) So to get around this problem, I have it set up so that I have a copy of the password-containing config file, minus the passwords in them. Whenever I make changes to the original password-containing files, I update the changes into the copies, and then track these copies in git, not the originals.

Not all config files need symlinks

In my last post, I discussed how creating symlinks via commands in the makefile was the key to this whole setup. But for some (smarter) applications, symlinks are not needed, since they can intelligently be told which config file to use. Alpine, icecast, irssi, and mpd are like this, so I just have config files for them inside my syscfg folder, and just run these apps (which are all autostarted for me each time on boot) with commandline parameters pointing to the non-default config file locations.

Unified Configuration File Setup Across Multiple Machines

SUMMARY: This post shows you how to sync multiple configuration files across multiple hosts with git and a makefile.

INTRODUCTION

If you have 20 different so-called ‘dotfiles’ like me, they can get difficult to keep track of. It can be even more difficult if you have multiple computers that you use often, and if you want them all to be updated to your latest settings.

For myself, I need to keep track of:

• .gitconfig
• .zshrc
• .zsh (folder)
• .vim (folder)
• .vimrc
• .gvimrc
• .vimperatorrc
• .Xdefaults
• .boxes
• .xmonad (folder)
• .xmonad/init.sh (custom init script that XMonad is told to call in the startup hook)
• .xmonad/xmonad.hs
• shellscripts (folder which has a growing number of custom shell scripts that I like to use every now and then, or at least keep as a reference on both my desktop and laptop)
• .xinitrc

Of course, this list will grow over time, as I start to learn more things and begin using more programs. What I want to do is (1) copy these files over to any other host that I use/own automatically and sync back to all the other machines any changes that I make to any one particular machine; and (2) have a unified config file structure, with a directory name for the application/setting, and a simple file called ‘cfg’ for the config file (which will be symlinked to what the application thinks is the true, appropriate location of the config file). The great thing about these two issues is that there is a simple, durable solution for these two precise concerns: git and make. So enough blabbering, let’s get to it!

Step 1: Put all config files into a new directory

It doesn’t matter where your new directory (let’s call it syscfg) is located. Move all of your config files that you want to keep track of into this directory. I suggest you rename all of them to fit some kind of unified naming scheme, and take note of what their former names/destinations used to be. For example, I use syscfg/vim to keep all of my vim things in there (instead of the default .vim, including a file called cfg to act as my .vimrc file).

Per-host (host-specific) settings

I highly suggest that you make all of your config files, such as your .xinitrc (or any other script or some sort) file, include per-host specific settings. Otherwise, you will have the same config settings on all of your systems! I.e., you’d want your .xinitrc to have something like:

do-something-universal-here
HOSTNAME=$(hostname)
case "${HOSTNAME}" in
    hostname1)
    do-something-here
    ;;
    hostname2)
    do-something-else-here
    ;;
    *) # catches all other hostnames
    do-something-else-that's-universal-here
    ;;
esac
do-something-else-that's-universal-here

The above syntax is for bash scripts (files that start with a “#!/bin/bash” at the very first line). If you are using zsh, you could also use this syntax for creating aliases that are specific to a certain host (e.g., my laptop doesn’t have 2 hard drives, so it doesn’t have aliases that point to my mount directory).

If your config file is painful to work with in implementing per-host settings (my xmonad.hs file is like this), you can still achieve per-host settings by making 2 config files, so for example cfg-host1 and cfg-host2, and symlink the correct one to .xmonad/xmonad.hs. You determine the correct config file to symlink to in the makefile. Read on.

Step 2: Create a makefile

Your sysconfig should now have a clean, uniform structure for all of your config files. Now, let’s create a makefile so that the program make can install and uninstall the symlinks as necessary. Here’s what my makefile looks like:

CFGROOT := $(shell pwd)
HOSTNAME := $(shell hostname)
all: boxes git shellscripts vim vimperatorrc xdefaults xinitrc xmonad zsh
boxes:
	ln -fs $(CFGROOT)/boxes/cfg ${HOME}/.boxes
git:
	ln -fs $(CFGROOT)/git/cfg ${HOME}/.gitconfig
shellscripts:
	ln -fs $(CFGROOT)/shellscripts ${HOME}/shellscripts
vim:
	ln -fs $(CFGROOT)/vim ${HOME}/.vim
	ln -fs $(CFGROOT)/vim/cfg ${HOME}/.vimrc
	ln -fs $(CFGROOT)/vim/cfg-gui ${HOME}/.gvimrc
vimperatorrc:
	ln -fs $(CFGROOT)/vimperatorrc/cfg ${HOME}/.vimperatorrc
xdefaults:
	ln -fs $(CFGROOT)/xdefaults/cfg ${HOME}/.Xdefaults
xinitrc:
	ln -fs $(CFGROOT)/xinitrc/cfg ${HOME}/.xinitrc
xmonad:
	ln -fs $(CFGROOT)/xmonad ${HOME}/.xmonad
	ln -fs $(CFGROOT)/xmonad/init ${HOME}/.xmonad/init.sh
#--------------------------------------------------------------------------------------------------#
# Since it's really painful to do a unified config file across multiple hosts in XMonad v. 0.8.1,  #
# I have to do it this way.                                                                        #
#--------------------------------------------------------------------------------------------------#
ifeq ('$(HOSTNAME)','exelion')
	ln -fs $(CFGROOT)/xmonad/cfg ${HOME}/.xmonad/xmonad.hs
else
	ln -fs $(CFGROOT)/xmonad/cfg-luxion ${HOME}/.xmonad/xmonad.hs
endif

zsh:
	ln -fs $(CFGROOT)/zsh ${HOME}/.zsh
	ln -fs $(CFGROOT)/zsh/cfg ${HOME}/.zshrc

uninstall:
	rm ${HOME}/.boxes
	rm ${HOME}/.gitconfig
	rm ${HOME}/.vim
	rm ${HOME}/.vimrc
	rm ${HOME}/.gvimrc
	rm ${HOME}/shellscripts
	rm ${HOME}/.vimperatorrc
	rm ${HOME}/.Xdefaults
	rm ${HOME}/.xinitrc
	rm ${HOME}/.xmonad/init.sh
	rm ${HOME}/.xmonad/xmonad.hs
	rm ${HOME}/.xmonad
	rm ${HOME}/.zsh
	rm ${HOME}/.zshrc

This is where symlinks reveal their beauty. From what I know of Windows XP (and my knowledge is very limited because I hate M$ with a passion), you cannot do something like this. Anyway, the above is fairly obvious and straightforward, isn’t it? All this does is create symlinks, and remove them if desired. Since they are symlinks, you can still do something like “vim ~/.vimrc”, and vim will read (assuming again that our directory is syscfg) syscfg/vim/cfg, with all of the pretty syntax highlighting and so on. The -f flag for the ln command simply makes it create the symlink even if the symlink already exists at the destination. See man ln for more info.

If you run make -B all, it will create all the symlinks defined under the keyword all. (The -B flag, for forcing make to run, is required here given our situation with symlinks.) You could in the alternative select only those config files you wish to install; e.g., make -B xmonad for installing only those symlinks for vim’s config files, or make -B vim zsh for vim and zsh’s config files. Lastly, running make uninstall removes all of the symlinks from your system. Experiment to your delight. (Make sure to have the lines with ln and rm start with a TAB character, as make will otherwise throw an error.)

Also, note how the contents in syscfg do not matter at all in how they are named, since it’s really the with its symlinks that takes care of all the proper “dotfile” namings.

Lastly, since these are all symlinks, you can have in your, say, .gvimrc file, a line that says “source ~/.vim/cfg”, and it will still work since the .vim directory is symlinked to your syscfg/vim (i.e., you don’t have to refer to symlinks once you make the symlinks). This is just a long-winded way of saying that using this symlink approach preserves all of your old config file paths from within your config files.

Step 3: Fire up git

Now, fire up git, add your config files, and sync it across all your computers! Use my post here to do this. The only thing to note here for our purposes is that the makefile is stored under syscfg, and that syscfg is where git should be initialized (with git init). Also, only add the config files and any other files that the config files depend on. An example of a file you should NOT want to add to git is any sort of history file, such as zsh’s history file (specified with the HISTFILE option in zsh’s config file — in our case, syscfg/zsh/cfg), since you’d want different session history files for different machines. Another example would be vim’s session files for the session manager plugin. If you add such temporary history files (or any other file that the application automatically makes changes to), you will make git track these changes (very doable, but utterly worthless)! On the other hand, you’d probably want to add simply script-like files that your configs depend on, such as vim’s various plugins (mere .vim text files in the syscfg/vim directory), or even irssi’s perl plugins, if you use irssi (I don’t use IRC on my laptop, hence it’s exclusion from my sample syscfg and makefile above).

With git taking care of the syncing, you now have complete revision history, as well as guaranteed config file integrity across all of your systems. It’s only a matter of cloning, then simply pushing and pulling for all of your config file syncing needs. Personally, I have it set up so that I just do “sl” to ssh into my laptop (sl is aliased to the unbearably long “ssh username@192.168.0.102″; no password since I have ssh set up that way; again, see my post above to do this), then “d sy[TAB]” (“d” is aliased in my syscfg/zsh/cfg to mean “cd”, and I only have one directory starting with “sys” so I can use zsh’s TAB completion to do the rest), and then “gpl” (extremely shortened form for “git pull” — again, see my post on git to make git accept this instead of “git pull origin master”). Yes, all I do is sl, d sy[TAB], gpl, and my laptop is synced. No more checking/rechecking manually whether certain symlinks exist on my laptop, and whether certain vim plugins already exist on it. I wish I had thought of this sooner, as it would have saved me a lot of time.

Reminders and other tips

• Make sure that all of your crucial config files (like .xinitrc) work properly before implementing this setup! (It’s not fun fixing things in the virtual console a la CTRL+ALT+.)
• Make sure to have per-host settings in each of your config files (or, failing that, have your makefile link intelligently to different config files on a per-host basis)
• In my vim config files above, you’ll notice that I symlink my cfg-gui to .gvimrc. The actual cfg-gui file looks very simple, with a “source ~/.vim/cfg”, and all the gvim-specific commands following that. Make sure to have a check for any autocommands so that they are loaded only once so that gvim works properly. (I must say, I only use vim now, except when I feel like seeing 16+ million colors (GTK) as opposed to 256 (urxvt).)
• The makefile, and its contents, can be scripted in a different programming language if you don’t want to use make. I’ve noticed that some people use ruby to do this. But it could also be python, perl, bash, or any other script.
• Since we’re going to end up putting into syscfg most of our config files, it wouldn’t be a bad idea to add files that don’t actually need syncing (see my note on irssi above). You’d just put an if-statement in your makefile to exclude these files for certain hosts. The benefit to this approach is that, you would end up with ONE git repo for ALL of your config files. Even though I’m not at this stage yet, I feel myself inevitably being pulled toward this path. I want complete revision history for all my /etc/X11/xorg.conf, /etc/fstab, /etc/sudoers, and even /boot/grub/menu.lst files, if it’s possible to do so. It’s probably a security risk to symlink to these destinations (file permissions, which git isn’t good at, at least according to what I heard from Linus’s Google Tech Talk from 2007), but I’m the only human who has access (and cares about) the config files on my desktop/laptop anyway. I’ll update this post if I end up achieving this “one config directory to rule them all” dream.

This guide was prepared with the help of various internet websites (google is your friend), and also especially this site.

Arch Linux + Xmonad

I finally got around to installing Arch on my desktop yesterday. At first I installed XFCE, and then Xmonad, and then I decided to dump XFCE altogether and just use Xmonad for all my computing needs. Xmonad is tricky to configure, so I only have a very basic xmonad.hs file (it’s the template config file found on the Xmonad wiki pages, minus the parts that give me errors on Xmonad 0.8.1).

I think tiling window managers like Xmonad are really the only way to go. I was getting sick of doing ALT+MOUSE2 to resize my windows to make most of my screen real estate on XFCE. I really like how my windows perfectly line up into neat groups. I haven’t even touched any of the great extensions out there for Xmonad yet.

In other news: I started using vimperator. It’s really neat once you spend 1 day with it. The biggest advantage for me: I don’t have to click on History -> Recently closed tabs -> tab to open up a tab I accidentally deleted. All I do instead now is just type ‘u’! And I don’t do CTRL+T, CTRL+K to do my searches — instead it’s now just ‘t searchterm’ or ‘t a packagename’ (where the ‘a’ is a keyword for the Arch Package Repository search engine). Woohoo!

Tips for Studying

Here are some random tips for being more productive with your time, especially studying, based on all my experience as a college student, and now a grad student:

1. Try to do things in natural lighting conditions. I.e., study in the sunshine (or if it’s too bright, indirect sunlight will do just fine). Your eyes will feel much better.
2. Never study more than 1-2 hours without taking a break. Breaking up your study session into smaller increments is a huge bonus. It gives you an opportunity to relax your eyes (look around your room, or even outside your window for a while), and you can also stretch around your body to get the blood flowing around again. You never want your bloodflow to come down to a crawl when studying. So stretch, walk around, and even do some pushups.
3. Change whatever you’re working on to something completely different, then come back to it for review. A good example: if you’re studying a piano piece by Bach, change to Beethoven or something else immediately after you reach one of your milestones. Or, do something completely unrelated. For me, this kind of randomization helps me retain more information when I come back later for review. The idea is to force your brain to rely on longer-term (longer than, say, your 5-minute memory bank) memory for whatever you were working on originally, when you come back to it later. I.e., what you’re doing is overriding any short-term memory you have on subject 1 with subject 2. This way, you’ll immediately notice any portion of subject 1 that you overlooked or didn’t really cement into your head when you come back to it later. As mentioned above, it works especially well for piano practice.
4. Repeat learned information numerous times. Use flashcards. Use Anki if you want to use flashcards on your computer or laptop.
5. Repeat learned information in different ways (the more different from the original, the better). I.e., do the same thing you learned — but do it differently. E.g., try playing a piano piece from the middle to the end, and then from the beginning to the middle. The idea is to program new neurons to redirect you to the same information. So if you have a math formula memorized, try repeating it aloud instead of writing it out. Write a haiku on it — it doesn’t even need to reflect with 100% accuracy what you learned. Draw a picture. The possibilities are endless.
6. Repeat information in various conditions, and not always when you’re in your “comfort zone.” E.g., repeat what you learned when you’re hungry. And when you’re full. When you’re tired, and when you’re not. It doesn’t have to be just emotional or physiological. It can be physical — e.g., repeat information while having cigarette smoke blown to your face. Repeat information when you’re drunk. Or when you’re on a caffeine rush. The idea is to force your brain to recall information even when in a real, significant state of stress. This is essential if you’re planning on becoming bulletproof in your recall of information in a high-stress environment, such as a final exam.
7. Try to draw connections between what you learned, and what you already knew beforehand (the more different, the better). A good way to do this is to draw as many analogies as possible. E.g., you read a book about a Roman Emperor. Was his life like mine? At which points? Maybe he resembles someone I know. This point is a variation of #5, but with a twist: this focuses more on bringing what you learned together into a more central location in your brain. I.e., if your brain is a statistical chart, what we are trying to do here is to remove any “outliers” and put them closer to where your existing information is. The idea is to remove strange or obscure information, and re-learn them as something familiar. This tip really shines for your most difficult and complex study material, and not so much for easy/less difficult material.
8. Stay healthy — eat right, and exercise regularly. This is the only way of ensuring that your body is giving good, rich bloodflow to your brain for your precious study sessions.
9. Sleep regularly! Sleep defragments your brain. There is NO workaround. Sleep, and even go for naps. More sleep = more retention of information.

That’s all I have for now. You should be well on your way to memorizing things by heart, “forwards and backwards,” if you use the tips above. They worked very well for me, and still do.

UPDATE October 31, 2008: Here are a couple more tips:

1. Break down complex material into its component parts. For example, before embarking on learning something, always read a summary of it first. By reading a cliff notes article, or even scanning the Table of Contents of a particular chapter, you begin the process of breaking down the material into easily-digestible components, even before you actually start “studying”. Just as a top notch mechanic knows every little detail of a motor engine, you need to make sure that you know every single component of a complex idea. Another way of saying the same thing is — chew before you swallow.
2. Explain what you’ve learned to someone who knows nothing about it. If you can do this easily, then you’ve essentially mastered the material. The person you’re explaining it to should be as ill-informed about your subject matter as possible. A skeptic is even better. The idea is to make that other person point out every single imaginable flaw in your understanding of the material. It’s like a torture test for your overclocked CPU. Can you handle the pressure, while maintaining coherence and integrity of your newly acquired data?

GTD – It Seems to Be Working

This is a follow-up post to my first post about GTD, the self-productivity system. The system seems to be working. My next actions list (or “actions list” for short), has steadily increased and decreased in items in the past weeks. I still haven’t broken down the gigantic projects I’ve documented into my projects list into bite-sized, do-able chunks to be incorporated into the actions list, but things are still looking very good.

I have less stress.

The overwhelming psychological benefit you get from knowing exactly where you are on the “Map of Life” feels great. It’s not so much of an energizing, high-five kind of feeling than a more relaxed state of existence. As I’ve said before, the GTD mantra of getting everything important out of your head and writing it down has really made me feel more in control of my life. If you’re really interested about GTD, google it or read my first post about it, where I laid out a brief, core summary of the system.

Getting Things Done (GTD) – First Impressions

So I checked out a copy of the renowned “Getting Things Done” book by David Allen. If you go to sites like lifehacker.com, then you probably heard about this system already. I can’t do a book review because I skimmed parts that honestly did not make sense to me. I’m writing about this book though, and the strategy of getting things done proposed by the book, because I think there are some points that is applicable to any system designed to maximize productivity.

First, the GTD way of doing things is not another time management system. The book talks nothing about how to spend your weekends or how to get that 20-minute nap in the afternoon. (Well, it does talk about doing your “weekly reviews” on Friday afternoons to go into the weekend with a clean slate, but really, this is just a suggestion that may not work for you.) It doesn’t really talk much about time at all. I like this aspect of it, because, in my own personal experience, flexibility to adapt your workflow to any situation is the key to increased productivity.

Now, to the basics. GTD, in its bare elements, consists of some rather simple principles:

1. Write down everything that you need to do. Write down everything that you want to do, as well. If anything comes up and you need to do it, or you want to do it, write it down immediately.
2. (Complete those tasks that you’ve written down–since they’re more manageable now due to your having written them down in a smart way.)
3. Once a week, review all outstanding/uncompleted tasks and plan for the next week. This is time to review any projects that need tweaking, etc., and should take a couple hours.

That’s pretty much it — Principle #2 isn’t really a principle as you can see, I just put it there to make the 3rd one make sense. Principles #1 and #3 are really, really new to me, and have given me some new insight into how to handle tasks.

The beauty about Principle #1 is that, once you do this, you don’t need to think about anything that has not been completed. And the lists that you end up writing up need not be detailed; for example, it could be something as vague as “learn to play the piano.” Once you’ve written this down, and you tell yourself that you don’t need to mentally remind yourself about this, you make room for other thoughts.

As for the actual tasks that really do need to get completed, you break them up into environments. It’s a to-do list, but a much better one, constrained (split up into subsections) by where you are or what you will have with you. Thus, the “Next Actions” list (GTD’s to-do list) may be composed of multiple lists like: @home, @computer, calls, emails, @work, @school, etc. See how these topics already make the decision of where you should be doing the tasks? This makes a huge difference for me. Try it out–this aspect alone will help you quite a bit–you’ll have to do less thinking about the task and how to do the task, when you’ve completed this first step of writing down tasks based on context.

About Principle #3: Apparently, this is the most important part of the GTD system (or any productivity solution). You should do your “weekly review” to take care of your various lists and “stuff” and make sense of them for the coming week. “Stuff” is anything that has not been processed, basically, into a “Next Actions” list. It could be your bank statement. A call from your friend Chris who wanted your input on deciding where to go for the ski trip. Emails. Ah, and that list containing things you want to do (like learning the Piano). “Stuff” is essentially any piece of information that has been given to you, about which you have taken no decisions how to deal with them. During your weekly review, you’re supposed to get everything that has piled up in your “stuff” bin and turn them into tasks for your Next Actions list. (My tip: make these tasks as bite-sized and friendly as possible to make sure that they can be knocked out one after another; there’s no point in writing into your Next Actions list something fuzzy like “plan a vacation trip for the coming holidays,” when “call travel agent” would be more to the point). And generally, this “weekly review” is the time when you take a step back from your tunnel-visioned Next Actions list, and try to get the big picture, and make any adjustments to your Plan for World Domination or whatever else plans/projects you might have (I’m assuming that everyone has such a plan, or set of plans, because otherwise, they are merely reacting to stimuli from their environment and not taking proactive actions about their lives). Also, it doesn’t hurt to do a monthly and yearly review to take a look at your more overarching plans/questions/ideas (your post-graduate plans, your questions about the meaning of life, etc.)

Allen does give some concrete tips to optimize the way this system works:

• Get a physical basket or tray where you can put all the stuff into one place for processing in your weekly review (I like this idea, and I started just putting everything in one pile in one part of my room for this purpose, since I’m too cheapo to buy a tray for this); Allen calls this basket/tray as the “in” basket in his book
• Only use your calendar to put things that are absolutely mandatory for you to do, or things that will by their very nature expire automatically after a certain date passes. This will make your calendar function as an instant visual check on which times are available for you to mold to your wish (your Next Actions list). Also, by keeping your calendar free and clear of any “to-do” activities that are less-than-mandatory, you will avoid the psychological letdown of seeing your commitments fail. Keep your calendar sacrosanct. (I like this tip too, and use it in my own calendar now. No more generic reminders on calendars!!!)
• Keep 43 manila folders. Thirty-one of those folders should be the days in a month, and 12 of them the months of the year (voila, 43 folders). This is, essentially, a gigantic calendar that has a 3rd dimension. The point is to use these folders as way to keep track of which tasks need to be completed on that day. So if one of your Next Actions list’s tasks was to go see the Super Bowl, you could put your Super Bowl tickets into the “21″ folder for the 21st of the month. The trick is to open the representative folder for the current day in the morning, and then take care of everything inside, or to use them as reminders; it’s like the President getting his executive morning briefing of all events for that day. Before you go to bed, you should take whatever is remaining in that folder, and move it into tomorrow’s folder. It’s quite an imaginative idea, I have to admit. However, I have not implemented this system because I don’t get enough “stuff” from people to really make use of all those folders. But hey, I’m sure it couldn’t hurt.
• Keep an archive. I.e., you should keep a file system for archiving material you might need later (aka “reference material”), such as phone numbers of people or a list of those new product lines that you wanted to take a look at in the future. Receipts, invoices, faxes, they all fit into this category. Allen doesn’t like hanging folders (I think it was because they’re weird to carry around with you), but hey, if you’re archiving material and you mean to keep them inside those big boxes or drawers, I don’t see why hanging folders can be such a bad thing).

It’s only been a couple days since I’ve implemented the essence of the GTD system, but I think it’s working. I feel less stressed out because of Principle #1 (see above). Also, it took me a while to write down everything that I want to do (learning foreign languages is a big one for me). I plan on breaking down every project/plan I have written down into smaller chunks that can be considered a task in the Next Actions list. Also, whenever I write down anything into the Next Actions list, I write down the estimated amount of time that it will take me to accomplish that task (always using conservative estimates), and also the amount of energy required for me to do it (is it creative work, or is it filling out a registration form?), in my own “code” language. This way, I can glance at the Next Actions list, and just see which one is the easiest one to do (or the hardest one, for that matter). (Again, the key is to prepare these tasks for ultra-easy consumption; more thinking at the processing stage (of the stuff) about how tough something will be will help you quickly choose a task from the Next Actions list and start completing it.) The time/energy requirement are not my inventions; Allen says that you should use these criteria when deciding which task to complete next — I just systematized it into the Next Actions list itself (much like how you break it down into @home, @computer, etc.).

Try it out. Get the GTD book for more details, but basically, as far as I can tell, everything I’ve written here is the heart and soul of GTD (the book itself is filled with the typical motivational testimonials and anecdotes that are entertaining, but are, really, just filler).