Guest Post: Implement a Mechanism-Based Lifestyle

Today I’m pleased to offer a guest post written by our good (and much cooler) friends over at Hack College. If you’re so inclined, check out the article I wrote for them: how I use “project queues” to stay focused. I think we can all agree: Nothing says Friday like co-located productivity fun!

Introduction

When programming, there are two ways to design a system: the bottom-up mechanism-based approach and the top-down policy-based methodology. From my Operating System Concepts book:

One important principle is the separation of policy from mechanism. Mechanisms determine how to do something; policies determine what will be done.

… The separation of policy and mechanism is important for flexibility. Policies are likely to change across places or over time. In the worst case, each change in policy would require a change in the underlying mechanism.

The Backstory

(Skip this part if you’re not interested in the knitty-gritty of computers.)

In the world of operating systems, there are two ways to accomplish something: a mechanism-based approach and a policy-based approach.

One of the things that makes Linux so great is its mechanism-based approach. Linux provides small but powerful programs to do simple things: ls, grep, rm, cat, less, and ps to name a few. Most of these microprograms can be mixed and matched to accomplish more complex tasks. Better yet, these can be built upon; most graphical programs in a Linux environment secretly call these command line programs to do the dirty work.

On the opposite side of the fence (usually) is Windows. Many design choices were made based on policies. A good example of a policy based implementation is a graphical program whose data files cannot be read without using that program or worse, a particular version of that specific program. Data hiding is sometimes necessary in computing, but in a Word file? C’mon.

Modulate to Graduate

For the record, I’m aware of my improper use of modulate in this context, but who can pass up a good rhyme?

One of the key tenants of computer programs these days is modularity. That makes perfect sense in my brain, but then again I like looking at the source code for Linux in my spare time. For those who don’t drool over code, think of modularity as Legos; a larger system built by many smaller, stand-alone parts.

The way us non-robots can implement such procedure is to break down tasks in life to their simplest level. Just about every single thing you do should have a consistent method of completion. Does this sound automatronic? It is. But the idea is to keep simple things off your mind, similar to what GTD tries to accomplish.

A Trivial Example to Demonstrate a Larger Point

All of this thus far may be a little too pie-in-the-sky. Let’s work with a concrete example. First, let’s talk about the how of something trivially simple: getting a phone number.

For most students today, the mechanism is: enter the data into my cell phone. It’s little surprise that everyone does this: it’s become the simplest single way to deal with the how of getting a phone number. The mechanism-based approach works well when getting the numbers out of your phone too: copy the data onto my computer.

Okay, this is lame, you say. Let’s look at the other way, the policy-based way of handling such a task. Policy just answers the what: record a cell phone number so it can be accessed later. When you are faced with the daunting task of recording a phone number for later use of some celebrity or CEO (or both), you might choke. Do I write down the number on my PocketMod? Should I just take his card and leave? Should I type it into my phone? By the time you figure out a mechanism to support your policy, you’re already toast.

Assembling the Blocks

The phone number example is trivial, but it proves a point. Have your mechanisms in mind when moving through the world. Whenever confronted with a task for your GTD, a phone number of an attractive member of the opposite gender, or a homework problem, train yourself to have knee-jerk mechanism based reactions. Break the problem down into discrete tasks and move forward. Your life will never be the same.

But wait! There’s more! Little did you know, I was taking you on a ride throughout this post. I used a mechanism-based style of writing! I wrote this post in several, small chunks that could be separated and still remain in context! Feel had?