Humility and judgement

Ran across a lovely quote tonight. It expresses well a basic tenet of mine, that people and groups do everything they do for a reason. I might not agree with the reason but every action grows out of the person or group's beliefs, values, and understanding of the situation. Of course, teasing out the real reasons behind an action is incredibly difficult and we almost certainly never succeed. But the effort to do so is always valuable and I don't think anyone can claim to understand much about the world if they resort to cheap caricatures when describing people and groups.

Nothing has changed me as much as trying to understand others.

In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."

This paradox rests on the most elementary common sense. The gate or fence did not grow there. It was not set up by somnambulists who built it in their sleep. It is highly improbable that it was put there by escaped lunatics who were for some reason loose in the street. Some person had some reason for thinking it would be a good thing for somebody. And until we know what the reason was, we really cannot judge whether the reason was reasonable. It is extremely probable that we have overlooked some whole aspect of the question, if something set up by human beings like ourselves seems to be entirely meaningless and mysterious. There are reformers who get over this difficulty by assuming that all their fathers were fools; but if that be so, we can only say that folly appears to be a hereditary disease. But the truth is that nobody has any business to destroy a social institution until he has really seen it as an historical institution. If he knows how it arose, and what purposes it was supposed to serve, he may really be able to say that they were bad purposes, that they have since become bad purposes, or that they are purposes which are no longer served. But if he simply stares at the thing as a senseless monstrosity that has somehow sprung up in his path, it is he and not the traditionalist who is suffering from an illusion.

The article the quote came from is well worth reading as well. http://www.janegalt.net/blog/archives/005244.html

December 30th, 2011

Building your own tools

I was explaining to someone in IRC earlier this week about why I was building my own project management software and said it was basically because managing my projects and tasks (or more abstractly, what I pay attention to) is so critical to everything else I do that I want to control the software behind it.

Afterwards, that struck me as a rather important point. After some further thinking, my point is fairly close to the common business question of whether a particular service should be outsourced or kept in-house. There's a lot that goes into making that decision but one pretty hard-and-fast rule is you never outsource a core competency.

I realized that in persisting in using poor-fitting tools for managing my attention, I had to some extent been outsourcing my core competency as a knowledge worker, i.e. defining what my work is and helping focus my attention. My ability to effectively do these two tasks has been hindered by using poor quality and poor fitting tools. As Marshall Mcluhan said, "we shape our tools and thereafter our tools shape us." Tools can be powerful inhibitors or powerful enablers in all sorts of subtle and unexpected ways.

The last few weeks I've started paying much closer attention to the quality and fit of my intellectual tools and if I should bring any of their creation "in-house" and recreate them to meet my particular needs. Which is a tricky thing to decide. You don't want, in a fit of vainglory, to go off and try to recreate Vim badly. I think in addition to my project management tool, I'll be building a few writing tools. Beyond that I'll wait to see how these first few experiments go.

What tools, intellectual or otherwise, have you built and how well did they work?

October 28th, 2011

Chatroom Feature for Drupal 6.x built with Node.js and Backbone.js

Recently, for fun and learning, I built a group chatroom feature for Drupal 6.x. I've been learning and using Node.js and Backbone.js the past few months and building a chatroom seemed like a great project to stretch my skills.

I've recently pronounced it "finished" and the code is available on Github. There are a few obscure bugs left but by and large, it's plenty stable for those wanting a chatroom on Drupal 6.x.

The feature should work with any site using Spaces and Organic Groups. The demo site I setup, for example, is using a default installation of Open Atrium.

Technology stack

The chatroom is built using a now fairly standard set of technologies. For the backend, I used Node.js, Redis, and MySQL. I used Socket.io for sending the chat messages between clients and the server. I used Brunch to build the frontend. Brunch bundles together a number of really nice tools for building single-page Javascript apps including Coffeescript, Backbone.js, Underscore.js, Stitch, and Eco.

A few conclusions

Backbone.js rocks. It makes creating highly interactive, responsive interfaces almost trivial while keeping your code neatly organized. It's a very neat round-up of the best patterns for creating Javascript applications.

Hand-rolling a way to securely connect Drupal and Node.js was a pain--probably the hardest part of building the feature. Use the Node.js Integration module if you're on Drupal 7.

Redis is really impressive. It has one of the shallowest learning curve of any technology I've used. I was up and running with it in perhaps 15 minutes. Add that it's incredibly fast and you have a very handy tool to add to your toolset.

Demo site

If you'd like to test out the feature, go to http://chatroom-demo.eduglu.com and try it out. I'd love to hear your feedback and if you end up using it.

October 12th, 2011

SimpleGTD

I'm starting work soon on building a new open source Getting Things Done web app that I'm tentatively calling SimpleGTD. I've tried a good chunk of the GTD apps out there and have been dissatisfied with each of them for one reason or another.

Motivations

I have a few reasons for starting this project.

First is I really like the GTD system. When it's running well, I really do feel more organized and able to focus on my priorities. But I've never been able to find a system that was maintainable long-term. I've tried many that worked for a time but each gradually required more and more effort to maintain until eventually I had to quit using them. I've thought a fair bit about why they've failed and I believe I can create an app that will actually work long-term.

My second motivation is there's a number of really cool technologies I'd like to learn or practice with including Node.js, Coffeescript, Backbone.js, ElasticSearch, Responsive Design, AppCache, and LocalStorage--each of which I'll be using to build SimpleGTD. It's really hard to learn new skills outside of the context of working toward a concrete goal so a nice compact project like this is gold.

My third motivation is to keep my startup "muscles" strong. For a variety of reasons, I'm not interested in doing another startup right now. But I will in the future. I plan to offer hosting and support for SimpleGTD app (for those not wanting to host it themselves). Doing the marketing, handling payments, support issues, etc. will allow me to practice all the parts of running a "real" company without the stress of caring whether my micro-business actually succeeds.

I have a number of similar side projects planned or in progress that I'll also be treating as micro-businesses. I'm building these projects primarily for myself but it'll be fun to also put them out in the wild and see what happens.

Key design principles

Fast

To quote Fred Wilson, "Speed is more than a feature. Speed is the most important feature. If your application is slow, people won’t use it."

More than any other flaw, lack of speed is the reason I eventually have quit the software GTD apps I've tried. Paper is really fast. Compared to a piece of paper or sticky note sitting on your desk, it's cumbersome to have to load a desktop or web app just to view your tasks.

To compete with paper, any software-based GTD system must load instantly and quickly show you exactly what you want.

Other actions, such as navigating, adding, and editing projects and actions must also be fast. My plan is that all movement within the application can be done via the keyboard, ala GMail.

To meet my speed standards, I'm going to use a variety of techniques. First all code and data will be stored locally using AppCache and LocalStorage. The app will load first from LocalStorage and only then sync with the server. This should solve much of the slow-start problem.

Second, I'll build the app as a single-page app. All communication with the server will happen asynchronously. This means viewing a project page or adding a new task won't require reloading the page so navigation within the app will be fast.

Simple

A big problem I've had with other systems I've tried is they're too complex for my tastes. They try too hard. I don't want to implement every idea David Allen has ever come up with. All I want my GTD app to do is add projects, add action items to these projects, and easily choose and sort the actions that I'll be working on the next day or two.

Paper-like simplicity is my goal here, not Microsoft Project.

Built for the 21st century

This is the 21st century. Almost everyone now is carrying around a smartphone in their pocket 24/7. No one prints off todos anymore. You should be able to select your action items for the day on your computer, walk out the door, open the app on your phone and instantly see what needs to be done.

Built to forgive and protect

The above ideas are fairly standard. My last idea is a bit more unique.

Keeping task lists is a hard discipline and almost everyone fails at times. Our tasks lists seem to quickly disintegrate into a disorganized, unwieldy mess without the occasional superhuman effort to clean things up. I'd like SimpleGTD to help us avoid that superhuman effort.

I think this is one reason I like paper. When a list of tasks on paper gets too overwhelming, you can just throw it away or bury it under other paper. Most GTD/Task software is less forgiving in this respect. If you add a project or task it's there forever until you explicitly delete it.

The problem is our brains has a selective membrane of sorts for commitments. It requires little force to insert a commitment but quite a bit of force to remove it. We're addicted to being "productive" and the rewards that come from completing tasks. With each added task, we imagine the praise we'll get once we accomplish it. Each new task is a shot of dopamine. Deleting a task or project kills the hope for that future reward.

In my past forays with GTD software, I would cheerful add tasks and projects much faster than I could finish them. They would accumulate and accumulate until I dreaded even looking at the software with its long list of uncompleted tasks.

What we have is a garbage collection problem. We accumulate projects and tasks don't throw out the ones we've abandoned. The garbage piles up higher and higher until eventually we have to abandon the house altogether and start a new one.

Like people portrayed on the TV show Hoarders, we find it difficult to throw away commitments.

I think the weekly review is what's supposed to corral this problem but I've never been able to do one consistently -- most likely because I dread having to decide what projects/tasks to abandon.

So what we need is to have the software help us to delete projects/tasks that we can't accomplish. As I've proven many-a-time, I can't manually keep my tasks lists in check. What we need I think is a Roomba-like garbage collector that detects dying projects and cleans them up for us.

But how to detect those projects/tasks that have gone stale--those projects/tasks that we've effectively abandoned but haven't yet told our consciousness? How can the software pick up on our unconscious cues that a task or project should be removed?

The best way I've thought of so far is to track how often we look at something. If we're actually working on a project or task, we'll be viewing or editing it fairly often. When we start to abandon a project or task, we stop looking at it. The software will track each time a project or task is viewed. If enough time passes since the last time you viewed the project, it'll be garbage collected and removed from active view. For tasks, they'll be removed from the active task list. For projects, they'll be moved to the someday/maybe list. And for projects already in the someday/maybe list, eventually they'll be moved into an archived list.

On timing, my thinking is tasks get garbage collected after 24 hours, projects after two months, and someday/maybe projects after six months.

So if you want a task or project to disappear, just ignore it and it'll eventually go away. Which follows our natural pattern. If we don't want to do something, we stop thinking about and eventually forget it. Most software has the annoying property of never forgetting.

At the start of the week, your active todos list should be white and empty, waiting for you to select the weeks tasks. If you load up a number of tasks at the beginning of the week but an emergency comes up, those tasks will silently disappear letting you focus on the emergency. If you're heavily focused for a few months on a couple projects at work, all our other projects will kindly hide themselves in someday/maybe. If we abandon the GTD-ship in despair, when we come back, all our projects will be waiting in storage and easily reactivated.

Moving forward

I'm really excited about my plans. It should be a fun project technically and is software I could really use right now.

How you can get involved

I'd appreciate feedback on my ideas. If you've tried and failed with GTD in the past, why did you fail? How did the system you used (software or otherwise) help/hinder you? Did my analysis, that failure comes from an overload of low-priority projects/tasks, resonate with you? Am I missing anything obvious here?

Once I get a usable prototype built, I'd love beta testers. Please contact me if you're interested in getting early access.

October 7th, 2011

It is the learners who inherit the future

"The central task of education is to implant a will and a facility for learning; it should produce not learned but learning people. The truly human society is a learning society, where grandparents, parents, and children are students together."

"In a time of drastic change it is the learners who inherit the future. The learned usually find themselves equipped to live in a world that no longer exists."
--Eric Hoffer

July 25th, 2011