Applying Unix Philosophy to Personal Productivity

After all..
another philosophy!!!!!!

 

 

Sent to you by pradeepu via Google Reader:

 

 

Applying Unix Philosophy to Personal Productivity

via Lifehacker: Geek to Live by Gina Trapani on 1/28/08

Reprogramming your personal workflow with a productivity system is a lot like programming computer software: given a stream of incoming information and tasks, you set up holding spaces and logical rules for turning it all into action. Like software that automates activities, good productivity systems take the thinking out of what to do with incoming data, and make it a no-brainer to turn those bits into an accomplishment. While I'm at best a novice student of Unix philosophy and its rules for designing great software, several tenets are worth thinking about when you're designing your productivity system. Many of the rules that apply to writing great code also apply to writing down tasks and projects that you'll actually carry out instead of put off. Let's look at a few of the basic rules of Unix philosophy and how they apply to your personal productivity system. Photo by naotakem.

The rules listed below come from Eric Steven Raymond's free online book, The Art of Unix Programming, specifically the section entitled Basics of the Unix Philosophy. Like I said, I am a beginning student of Unix philosophy, so I welcome the hardcore Unix beards in the house to correct any misinterpretations or wildly loose applications of these rules that follow.

From the 17 rules of Unix philosophy listed in Raymond's book, here are just a few that particularly apply to reprogramming your workflow:

Write simple parts connected by clean interfaces.

(Rule of Modularity)

While much personal productivity software attempts to do everything for you—include contacts, tasks, projects, email, and calendar into one monster package—there's a big advantage to using separate mechanisms for each job. If there's one you want to upgrade or change one aspect of, you can do that without trashing the others. For example, if you tie up your whole life in Microsoft Outlook, moving to a different email or calendar app gets complicated. Likewise, favor apps that have universal interfaces—like RSS feeds and email alerts, or the ultimate universal interface, paper.

Raymond writes:

The only way to write complex software that won't fall on its face is to hold its global complexity down—to build it out of simple parts connected by well-defined interfaces, so that most problems are local and you can have some hope of upgrading a part without breaking the whole.

Clarity is better than cleverness.

(Rule of Clarity)

When you're writing down your events, to-do's and projects, make the instructions you're giving yourself as clear and easy to understand as possible. "Found a company" is a huge, unspecific project that will sit on your list undone forever. "Call Tom to ask how he established his LLC (555) 456-7890" is a much more doable task. Further, when you're tempted to come up with a complicated, coded, hierarchical, contextual tagging vocabulary and sorting algorithm, remember that clarity is better than cleverness.

Code that is graceful and clear is less likely to break—and more likely to be instantly comprehended by the next person to have to change it. This is important, especially when that next person might be yourself some years down the road.

Fold knowledge into data so program logic can be stupid and robust.

(Rule of Representation)

Include all the information you'll need to get stuff done into your system at the entry point. For example, if you have to make a phone call, include the number when you add the call to your to-do list. If you have to go somewhere you've never been before, include directions and address and contact phone number. Make your data as rich as possible, as your system is just a path for moving things along.

When you must fail, fail noisily and as soon as possible.

(Rule of Repair)

The idea of failing "noisily" is not something our culture encourages, but it is the only way a programmer can diagnose and fix a problem. If you've spent time setting up a productivity system (whether it's GTD or just using a new task management app) and you screw up, stop. Figure out all the reasons why you forgot Mom's birthday, missed a deadline, or never followed up with that guy about that opportunity. Be verbose about it. Make a point to "fail noisily" in your mind and tweak your system to prevent it from happening again. Like software development, your productivity system development is an iterative process.

Programmer time is expensive; conserve it in preference to machine time.

(Rule of Economy)

The Rule of Economy could be Lifehacker's mantra. In short, don't do anything the computer can do for you. Instead of wasting time painstakingly filing all your documents into perfectly named folders? Search for what you need on the fly. Learn keyboard shortcuts to avoid having to move the mouse excessively. Automate boring tasks like backing up your files so that you don't have to spend time doing it. Make your computer work for you, instead of you working for the computer.

Prototype before polishing. Get it working before you optimize it.

(Rule of Optimization)

There is no perfect productivity system. Actually, scratch that: the perfect system is the one you're using. You don't have to have the Getting Things Done book memorized to get started organizing your stuff. Decide on one method for getting organized and start using it. Then, tweak as you go. Your productivity prototype should be "live" before it's been optimized. Work your system no matter how imperfect, and modify it as you go.

Design for the future, because it will be here sooner than you think.

(Rule of Extensibility)

Will you be using that email address, that copy of Proprietary Expensive Company-Licensed Software & Trade, that handheld, forever? Future-proof your productivity system by choosing tools you own and that don't lock down your data into proprietary formats so that you can take it with you going forward.

Developers, programmers, and code monkeys, do you see any more similarities between reprogramming yourself and writing code? Tell us about it in the comments.

Gina Trapani, the editor of Lifehacker, needs to tattoo the Rule of Clarity to her forehead. Her weekly feature, Geek to Live, appears every Monday on Lifehacker. Subscribe to the Geek to Live feed to get new installments in your newsreader.

 

 

Things you can do from here:

• Subscribe to Lifehacker: Geek to Live using Google Reader
• Get started using Google Reader to easily keep up with all your favorite sites