Using the Junk E-mail folder to your advantage

image

So, when I said that I don’t use folders to manage email, that was a small fib. Truth be told, I do use the Junk E-mail folder. Here’s why:

Even with all my filters and categories (a.k.a. tags), I still receive more email than I care to triage. For example, now that I’m working with my new team, I get email about all of the support tickets that are sent to the team – even though I’m not capable of responding to any of them.

When I first joined the team, these messages were appearing in my “Important” category because all mail sent to the team DL was flagged as important. I soon realized that some of the mail was not as important to me as it might be to the rest of the team. So…

I tried demoting that mail (mostly from bots) to “Interesting.” This gave me better visibility into my “Important” mail, but simultaneously clouded my view of my “Interesting” mail – mail from executives and my favorite distribution lists. So…

I demoted these messages again, to “Neither Important nor Interesting.” This allowed me to focus on the really important and interesting things. But, it still meant that I had to either flag them as complete, or delete them to get them out of my Triage folder so I could experience that tiny little peacefulness that comes over you when you reach Inbox Zero. So…

I made the decision that I should just delete these messages when they arrive since I never read them anyway. But, since I’m always afraid that a rule will delete something I don’t want deleted, I chose to send these messages to my Junk E-mail folder, instead of deleting them.

This has worked out incredibly well. As the messages arrive, they are automatically triaged out of my triage folder. So, I can completely ignore them until the number on that handy little icon gets uncomfortable, at which point I quickly check the folder to make sure there’s nothing important, then delete my Junk E-mail. (Usually, around 30 messages hits my personal threshold.)

From Password Strength to Privacy

At it’s core, password strength is about privacy. Well, that and theft prevention.

One of the blogs I follow had a thought provoking piece on privacy in the age of the Internet, today. I wanted to blog about it. But, I couldn’t put it any better than Tweetage Wasteland already did.

And, yes. I read the Confessions of an Internet Superhero.

Inbox Zero!

Last year, about this time, I described my personal system for dealing with the large volumes of email that I saw at Microsoft. As hard as I try, I’m not always successful at keeping my Inbox (or in my case, my Triage folder) at zero, even though the volume of email I receive here now is significantly lower. On occasion, however, I do get to see what it looks like, so I thought I’d share:

image

There’s a couple of things to point out here:

  1. My Triage folder is empty. (Inbox Zero!)
  2. My To-Do Bar is full of scheduled tasks. (I use flags to schedule things.)
  3. My tasks are color coded, as follows:
    • Red = Important
    • Orange = Interesting
    • Yellow = Neither
    • Green = Personal
  4. My tasks for Today are sorted in priority order (by manually dragging them around).

The one weakness I have with this system is that I sometimes drop tasks that people give me verbally – like in meetings. My system works best for me when I have an email trigger to remind me to go do something. I’ve been trying to be more proactive about asking folks to send me reminders. But, maybe I should just email them to myself.

Coding Standards

One of the original practices of Extreme Programming was coding standards. Back in 2000, when I read my first XP book, I tensed up a bit at the thought of having to make my code look like everyone else’s. But, over the years, I’ve come to see the wisdom of it: once all the code follows the same standard, it becomes much easier to read.

In fact, now a days, I often reformat a block of code to meet a coding standard before I try to figure out what it’s doing. (But, only when I have strong unit tests!) Long story short, I haven’t had a good knock-down-drag-out argument about curly braces in nearly ten years! (Anyone want to have one for old time’s sake?)

With that in mind, I needed to look up Microsoft’s latest guidelines for .NET class libraries, today. Specifically, I knew they said something about using abbreviations and acronyms when naming things. But, I couldn’t remember exactly what the recommendation was. So, I looked it up. Turns out, Microsoft has done a rather nice job of structuring their design guidance on the web.

It’s not something you’ll need to refer to everyday. But, it’s good to know it’s out there…

http://msdn.microsoft.com/en-us/library/czefa0ke(v=VS.71).aspx

An Agile Approach to Mission Control

NASA’s Cassini spacecraft has been studying Saturn, it’s rings and moons for nearly six years, despite the original mission being slated to expire after only four years. But, due to better than expected performance and lower than expected fuel consumption, NASA has extended the mission for an additional seven years, to 2017.

In order to negotiate the flight path for the next seven years, the engineers in charge of planning the orbital maneuvers consulted with the five science teams affiliated with the project. Each team is assigned to study different things: Saturn, Titan (Saturn’s largest moon), the rings, the icy satellites, and the magnetosphere. Each team presented their wish list for the places they’d like to see over the next seven years, and the engineers got busy running the numbers:

The first time [the engineers] met with the discipline teams, they offered three possible tours. The next time, they offered two, and, in January 2009, the scientists picked one of them. Last July, after six months of tweaking by [the engineers], the final “reference trajectory” was delivered. It now includes 56 passes over Titan, 155 orbits of Saturn in different inclinations, 12 flybys of Enceladus, 5 flybys of other large moons — and final destruction.*

In essence, this team of engineers had to balance the wishes of the five research teams with the remaining fuel and gravity boosts available. The approach they took was to present alternatives and iterate on them until they found the best solution, given the requirements and the constraints:

“It’s not like any problem set you get in college, because you have so many factors pulling in different directions,” Mr. Seal said. “The best way to measure it is to look at how much better the next iteration is than the previous one” until “you’re only making slight improvements.” Then you stop.*

I can’t think of a better way to describe the iterative development process espoused by most agile software development methodologies, including Scrum and XP. You know when to stop when the remaining improvements are no longer worth the investment.

I wonder how many of our customers would like to see three options, then two, then one…

* http://www.nytimes.com/2010/04/20/science/space/20cassini.html