The fastest way to triage email

It goes without saying that your inbox needs regular management, or it’ll be full to overflowing. Either way, every day more stuff comes in for you to remember to do. Some of it is urgent and gets handled by you immediately; some of it is temporarily or permanently ignorable, and will work its way off the bottom of the list as you handle more important things.

Years ago, after too many forgotten tasks and missed deadlines,  I read a copy of Getting Things Done by David Allen. I followed its excellent prescription for getting your life’s tasks under control. I keep spare copies of this wonderful book in my office at all times, to give to people that I think might need or want to read it. I pick them up in used bookstores whenever I find a reasonably priced copy.

I won’t go over the GTD approach to inbox triage here, as there’s so much written about it everywhere else on the internet; but I used it for years. It’s a rather zen-like process for making sure nothing slips through the cracks. But over time, as I progressed from my small company to larger ones, and from individual work to management, I began receiving more emails every day. Email-wrangling began to be something I spent a significant amount of my day doing, which stunk.

Eventually, I started experimenting with cutting corners to reduce my email time. What follows is the method for email triage that I eventually settled on. It’s a variant of the GTD method — it has the same output (i.e. things in to-do lists, and an empty inbox), but for some reason I can do it in much less time.

First step: Create two folders named __ARCHIVE__ and __HOLD__. In Outlook you can create ‘action buttons’ that, when clicked, will move the selected email to each folder — I recommend creating them if you’re in Outlook. Not sure what the equivalent thing is in gmail.

Second step: Start at the top of your Inbox list and ask of each item: Is there anything in here that I have to do? If the answer is yes, move the email to __HOLD__. If no, move it to __ARCHIVE__. Continue until the email Inbox is empty.  That’s the end of “Phase 1”.

EmailTriage1

Third step: Now move over to the __HOLD__ folder and start at the top. Each email that’s now in __HOLD__ had some action item or task associated with it; as you read each email, put the associated ‘next action’ into a separate list (I like using Workflowy for this purpose). If you’ll need to read the email later for reference, when doing the associated task, also flag (Outlook) or star (gmail) the email. Then move the (flagged or unflagged) email to __ARCHIVE__. Continue until the __HOLD__ folder is empty.  That’s the end of “Phase 2”.

EmailTriage2

That’s all; your to-do list is populated, and both Inbox and __HOLD__ box are empty.

You’ll notice that with this system, everything ends up in the __ARCHIVE__ folder; I rarely if ever delete emails, because I never can guess which ones I’ll need again. Anyway, the time I spend dithering about whether it’s too important to delete is time I’d rather save.

I used to keep emails in separate folders (such as DEFERRED, DELEGATED, etc), thinking this helped to keep me organized; but I gave this up. The search function in the single __ARCHIVE__ folder does a better job. I flag the emails I know I’ll need to find again, but only because the flags help to make them ‘pop’ visually in the midst of all the other emails.

Carolyn’s first law

Years ago, I left academia in Florida for the promised land in Colorado, and took a Senior Researcher job at a firm that specialized in Synthetic Aperture Radar (SAR) applications, including the production of digital elevation models (DEMs) derived from SAR images. I remained there for quite a while, writing lots of proposals, working on small government contracts (SBIRs and BAAs), and doing occasional consulting.

In the early 2000s, we were subcontracted by one of the large government contractors to develop a system for tidying up the large volume of digital elevation models (DEMs) that had been produced by the Shuttle Radar Topographic Mapper mission in February 2000. It was the first team software project that I or my company had ever been involved in, with (at its peak) about 12 developers working on software that would be used by production analysts in Pittsburgh to delineate, and set the elevations of, lakes and rivers.

Suddenly, our little team of SAR experts (who had never developed software in teams) was press-ganged into serious software development. One particularly introverted fellow, call him Dave, was assigned to work on a skeletonization algorithm as a part of the algorithm that would be used to step down rivers. As chief stepper-down of rivers, I needed to call his function as part of the code I wrote to set river elevations.

As requested, he had provided me with a C function to calculate the skeleton of a shape delivered as a binary image consisting of 0s and 1s.  But the function didn’t take a pointer to a binary image as an argument; instead, it took the path to a system file containing the image. Dave had never done any GUI development; he wrote simple C code as executables that ran from the command line.

I went to speak to Dave about it (I confess I had never really spoken to Dave before, and was a bit frightened).

Me: Dave, I need you to change one small thing about your code.
Dave: I’m not changing anything about it. It works as requested, and I’m done with it. If you wanted it to be different, you should have said something before I wrote it.
Me: But this is GUI code. The pointer to the image needs to be passed into the function. It can’t read the image from a file system. That’s stupid*.
Dave: You should have told me that before I wrote it.
Me: Dave, if you won’t do it, I’ll have to change your function.
Dave: Don’t touch my code; I’ve debugged it, and you’ll mess it up.
(Remainder of conversation mercifully snipped).

Since we had all never heard of anything like a development manager, there was no one to appeal to; so I wrote a wrapper function that took a pointer to an image and dumped it to a temporary directory on the file system, so that Dave’s code could read it back in.

Soon afterward, we were sitting around a bar discussing the project and philosophizing about its larger meaning. Apparently at some point I said:

“Anybody looking at that stupid bit of wrapper code will wonder what was wrong with us. They won’t realize that that code is just frozen evidence of our team’s social dysfunction”. Fortunately my husband was present to remember that I said that, because in the years since, we’ve come across a lot more social dysfunction in the form of code.

He eventually dubbed it “Carolyn’s first law” in its final form: “Software is the social dysfunction of an organization in frozen form”.

* I’ve learned, since then, to never suggest to another developer that his code is stupid.

 

Crowdsourcing field boundaries in Mali

In the last year, we’ve worked on quantifying agricultural yield in Africa using EO satellite imagery. Identifying field boundaries is always the starting point for agricultural studies, and it would be great if we could do it automatically. In America you see agricultural fields that are uniform, cleared, and irrigated; but, in Africa, smallholder fields tend to be none of those things. Looking at ag images from Africa, and thinking about delineating African agricultural field boundaries, will soon have you questioning whether the idea of field boundaries really makes any sense at all when a field might have several different crop types, a few trees, and a huge termite mound in the middle of it.

But land tenure, and whether it can be ascertained on a large scale from remote sensing imagery, is a problem of interest to agencies working on sustainable land development. There are clues as to where the boundaries of fields are: the field treatment may change, or there may be tree lines, paths or rivers. But sometimes it takes a judgment call, and you get the best judgments by asking a lot of people their opinions.

So we recently kicked off a crowdsourcing campaign on the Tomnod crowdsourcing website, using Tomnod’s new polygon Draw capability, to try to solve the problem. We asked the Tomnod crowd to collect field boundary candidates over a small ag scene in Mali, using intuition with only a few guidelines. I drew a bunch of field boundaries for the campaign, and found it a very easy interface, fun and kind of addictive. So far, the crowd has drawn about 6000 field boundary polygons.

But where is this going? Here’s what I’m hoping:

  1. In the end we’ll have a number of candidates for possible fields, contributed by different individuals. ‘
  2. We’ll identify the serious field candidates based on a validation campaign, or some sort of consensus measure.
  3. We’ll aggregate them into a ‘best field’ estimate, in the same way that taking an average of a set of estimates of a number improves the estimate of the number, by reducing error.
  4. We’ll either use the high-quality results themselves, or we’ll have a rich set of training data for developing a machine learning approach to automated field boundary delineation.

I love QGIS

QGis_Logo

QGIS (formerly Quantum GIS) is an open-source, freely distributed software package for viewing and working with geospatial imagery and vector data. It has much of the same functionality that ESRI’s ArcGIS software has. Since ESRI stands astride my industry like a colossus, I suppose that part of the reason for my fondness for QGIS has to do with my tendency to root for the underdog, but I’ve used it quite a bit over the last year and I’m delighted with it.

I’ll go out of my way to use free and open source software rather than commercial software. I used to work for a small remote sensing company that ran on a shoestring, and much of what I did had to be done using free software. At the time (in the late 90s) there was no freeware alternative to ESRI’s ArcGIS other than early GRASS GIS, which was difficult to build and use. At the time I needed mostly to view and process SAR imagery, and for that I used PCI; later, after my company bought Atlantis Scientific in Ottawa, I became an user of their Openev software (which is idle now, but still exists for download on Sourceforge).

It was difficult to be an open source GIS user back then. Not any more, since QGIS has not only an intuitive user interface (not easy for GIS software, which has a lot of moving parts), but has also incorporated most of the other free GIS software that has been developed over the years. QGIS also makes it easy to import and use 3rd party content, including Bing and Google image layers and OpenStreetMap. Furthermore, it’s straightforward to build your own plugins for it in Python, or even to use its constituent libraries to build your own application outside QGIS if you wish.

There is another reason for Arc users to get to know QGIS; if you are working with a customer who needs to use GIS software just once, or who want to learn to use GIS themselves but are operating on a limited budget, the need to purchase commercial software can be a showstopper. QGIS is, conversely, an easy and free download and install, with plenty of online tutorials and support.