The Getting Things Done methodology encourages behavior such as Inbox Zero, the concept of dealing with all the items in your inbox and keeping a zero count. In previous jobs, I’ve tried to do this, and struggled at times, having as many as 1000 items. Even when triaging my inbox regularly, I’d still end up with 50 items that needed some sort of attention.
Lately, I’ve been using Gmail for personal and work email, and have found a balance that isn’t as stringent as inbox zero, but eliminates most of the mail. I call it Inbox One, as in one page of email. At any given time, I have at most enough email to fit on one page. As soon as it gets larger than a page (or I get a downturn in work), I clean it out as much as I can.
Currently, I have 3 items in my work inbox (up 50% from this morning, oh no!) and 10 items in my personal email inbox. Only 1 of those 13 items need attention today.
I still follow the Inbox Zero teachings, but try to be a little more pragmatic. Not everything needs to be handled immediately, but as much that can be dealt with quickly, or properly scheduled as work to do in the near future, I take care of. What is left are a few items that eventually need to get done. Like Inbox Zero, anything unimportant is archived, deleted, or filtered.
Inbox Zero is near impossible to maintain all the time unless you are very self-disciplined. Inbox One is far more tenable.
An “old” adage in development is “release early, release often”. This is a form of iterative development which allows for lack of functionality initially, and additional function in short releases afterwards. It’s helpful, because it gets your site in front of real people, quickly.
I recently tried this approach with machine2date and SharedBetween.Us
machine2date is a site that focuses on one thing, converting “computery” dates into dates people recognize. If you do JSON or XML in your development, dates like “\/Date(1240718400000)\/” don’t mean much to anyone but a Unix time programmer (it’s ticks since January 1st, 1970 at midnight.)
SharedBetween.Us started out as something that was much simplier than what it is today. It’s a simple task list that can be easily shared between users. It was originally “SharedLists”, but the domain was taken, so I lazily renamed it to its current name.
Both of these sites are easy to make changes to and deploy quickly. A lot of the friction in deploying is managing releases and doing the physical deployment. The combination of git and AppHarbor makes setting up a new site stupid-easy. In 15 minutes, you can likely do all of the following:
- Create an AppHarbor application
- Buy a domain name
- Setup DNS to point to AppHarbor
- git init (in the root of the application or webpage you’d like to deploy)
- git add .
- git commit -m “your comment here”
- git remote add appharbor http://username@your.appharbor.url… (Your URL is easily viewed on the AppHarbor application page after your complete step 1)
- git push appharbor master
That’s it. To update the site, you may need 3 minutes. Just do the following:
- Make update to application or webpage. Trivial changes or spelling corrections no longer need to wait for a “full release”.
- git add .
- git commit -m “your comment here”
- git push appharbor master
AppHarbor explains it all here. There’s not an excuse to do an initial release. Or a simple update.
The newest version of Nuget, version 1.6, wouldn’t update on either of my computers from within Visual Studio. I’m not certain why, but the fix is simple. Run Visual Studio as administrator, go the Extension Manager, uninstall Nuget, restart Visual Studio, and reinstall. Don’t bother uninstalling from Add/Remove Programs, it’s a trap!
I’m not sure where I first read about “distraction free Visual Studio”, but it’s a thing, and I quite enjoy it. This article explains how to take to the extreme. At a minimum, I suggest turning off all your various toolbars. How often do you really use them?
