battle against time

Like many people, I get a lot of e-mail every day, and I spend a very substantial part of my time processing them. In order to keep things under control, I'm following a number of practices, which I'll describe in the following. As with most good ideas, it's not my own idea -- it's inspired by a time-management method called Getting Things Done (GTD). More about that later.

inbox zero

So how to become in control of our e-mail again (instead of the other way around)?

The most important rule here is that we should always end the working day with an empty inbox. Fantastic as that may sound, it's really the key here. So, how do we do that?

• At least once a day (and before leaving the office), review the messages in your inbox. For each message, decide what to do with it:
  
  
  
  1. If it requires some action:
     
     
     
     • if it takes less than two minutes: do it now;
       
     • If someone else can better handle it: delegate (forward) it;
       
     • otherwise, move it to a folder NextActions;
       
     
     
  2. If might be interesting or important later, archive it
     
  3. Otherwise, it's just crap - delete it.
     
  
  
• After this review round, your inbox will be empty. No message stays behind - look at them, and decide where to move them.
  
• Now, periodically check your NextActions, take the necessary actions, and move messages to your archive after completing them. (I've found that maybe only one-third of my incoming e-mail end up in NextActions)
  

That's all there's to it. Following these simple rules, it will be much easier to deal with lots of e-mail. If you have 250 e-mails in your inbox, some of which are weeks old, it's really hard not to forget something important; also, it costs a lot of time to scan those same messages again and again (I'd say handling a mailbox with n mails has at least O(n²) complexity :-).

Of course, this is just a starting point; you could add WaitingFor-folder with a copy of mails you delegated (forwarded) for tracking. You could somehow add the calendar. You can add other to-do items. You could think of some smart way to manage those items in NextActions. And so on... All of those things are discussed in GTD.

gtd

Getting Things Done (GTD) is David Allen's method of time management, which deals with much more than just e-mail. The steps above are a sort-of GTD-light that works very well for my e-mail. Anyway, I can really recommend the GTD-book for anyone interested in time-management. It's a rare gem in the sea of 'personal-productivity' books. Read an overview on the 43 Folders-website, or their excellent article on inboxzero, which has lots of additional tips.

I've been using GTD (and especially these e-mail handling practices) for quite a while now, and it has really saved me a lot of time and frustration. I'm quite sure this will work for a lot of people; but of course, the only way to really find out is to try it out yourself. On the internet, GTD enjoys an almost cult-like following on the web - don't let that scare you away. Just be skeptical, and use what works for you.

epilogue: gtd on n8x0

You could implement quite a bit of this on your N8x0 and (surprise) modest, and I have done so quite succesfully. What's still missing is some calendar integration, and an easy way to handle (search through) huge archives of messages. Anyway, being so mobile, the N810 with modest has become a great productivity tool for me.

One geeky alternative would be to use Emacs; people like Sacha Chua and others have written a lot about using Emacs for Getting Things Done. Now all we need is to port emacs to the N810 -- project maemacs to the rescue! Or maybe someone could make an N8x0 version of Chandler? (unfortunately, the book is still better than the program).

kill 'em all

The last few weeks, we were suffering some instability in our beloved modest e-mail client. At specific time as well as randomly, modest would decide to call it a day, and prematurely return its pid to the rightful owner. Bug reports are not always enough to pinpoint the problem (which might be outside modest) and it's easy to be misled in some direction. We spent quite some time with the various tools at our disposal. All have their specific strengths and weaknesses, so we tend to use them combined. Let's discuss some of them.

gdb

First, there is the venerable gdb. Although armchair computer scientists snuff at the use of debuggers, down here in the trenches, it's often our last hope. Using gdb effectively takes time, and various extra difficulties (scratchbox, the ARM architecture) can make it a frustrating activity. And for people used to graphical debuggers (like the one in Visual Studio), gdb might seem a bit spartan, even when using something like GdbMode in Emacs. But once you've become friends with gdb, it's an incredible powerful tool, which even works on your N8x0.

As a small tip, in OS2008/Chinook provides the maemo-debug-scripts package, which (among others) offers native-gdb. I'm not sure what's so 'native' about it, but it provides gdb 6.6, which works much better than the apparently 'non-native' gdb 6.4, especially with threaded code. It's not clear to me why the ancient 6.4 is shipped in the first place, but there's probably a good reason. Read more about it here, which has a lot of very practical tips.

valgrind

Then we have valgrind (pronounced vel-grinned). Compared to gdb, which is like a brain surgeon, valgrind resembles a tax auditor (hurray!), with bytes in your RAM as the currency. Valgrind runs your program in a virtual machine, which offers replacements for the normal memory-management functions (malloc, free and friends). When running with valgrind, the application uses valgrind's replacements. And unlike the normal ones, valgrind's versions carefully checks where you get your memory from and what you do with it, and whether you free it when you're done with it.

It's an extremely useful tool for finding memory errors that occur during runtime. One weak point of valgrind is that it doesn't run on ARM; but still, it's a great way to find memory corruptions, leaks and so on, which will show up on X86 as well. Any kind of memory error found on X86 corresponds quite likely to a crash on ARM.

Note that I've only talked about the 'memcheck' tool inside valgrind; there are many more, such as cachegrind, massif and the new iogrind, which are great for profiling your code.

A relatively recent version of valgrind is available in the OS2008/Chinook repositories.

static checking

Except from these runtime tools, there are some other ones, which work at the static, source-code level. There are things like Coverity and lint, but in my (limited) experience, they only catch a small number of problems much that weren't also caught by gcc with -Wall -Werror + valgrind/gdb. Still, it's quite attractive to use any kind of bug prevention you can get your hands on. And let's not forget one of the most important tools: careful code review. Finding some critical part of code, and then simply reading it, letting the statements play out in your mind, and imagining the interactions. The human mind is the greatest debugging tool of all (and a pretty good bug-introduction tool too... )

Now, I hope you can find a bright mind somewhere yourself... Regarding gcc, version 3.4.4 is available in OS2008/Chinook, but modest can be compiled as well (outside scratchbox) with gcc 4.2, using Ubuntu Embedded, or the rudimentary gnome-frontend. Compiling there, and on a 64-bit architecture, helped to fix some issues as well. And the newer gcc is much better at detecting with -Wall.

so far, so good... so what

Now, even with all these tools, I can promise that there are still some bugs left in modest. But also that there are quite a few less. So please get your latest update at the usual place (the application manager). If you find any kind of instability, please file bugs at the usual place, and please describe as detailed as possible what you were doing -- thanks!

keep on rockin' in the free world

Ok, I guess it's still in time to wish people a happy new year. Apart from the obligatory sessions of eating, drinking and reconnecting with my inner-child, Christmas has been a great time to enrich the internal uranium, and I feel full of ²³⁵U again. I'm sure I'll need plenty of it in the new year. So, once more, best wishes to all, at let's make the world a better place in 2008.

One thing to get there is of course is to polish that raw diamond that we call modest. I've been quite happy with the progress we've made since our bèta less than one month ago. We've closed quite a number of bugs, and made steady improvements in performance and the handling of specific emails and mail servers. And we've been making frequent releases, roughly every week. If you're using these weekly updates, you might not necessarily see so much difference between versions, depending of course on your particular use case. But believe me when I say that we are not sitting still :)

Anyhow, there are a couple of problems we're looking into now:

• first, performance problems with really big folders (ie., many thousands of mails). We're trying to come up with a solution, but it's not easy (as is the case with most interesting things in life). Please bear with us;
  
• second, problems with specific servers. Here you can help us! We're testing modest with different POP/IMAP/SMTP servers. But, there are many more different ones in the world, with a wide variety of versions, configurations - a combinatorial explosion. If your server doesn't play nice with modest, please file bugs with all the details (server, version, configuration,...). Also, protocol traces or PCAP-files (tcpdump/wireshark) are very useful, as are test accounts. Remember, if we cannot reproduce it, we probably can't fix it. If there's information you don't want to share with bugs.maemo.org, you may also mail me directly. That does require you to trust me, though.
  
• finally, we've seen some problems with rare emails not being shown correctly. Again, if you get such an email, please file a bug, and attach the email (after stripping it of any privacy-sensitive information of course).
  

Anyhow, for the large majority of users, modest seems to be working quite nicely; if you haven't tried it yet, I invite you to give modest a try, and tell us what you think.