Pragmatic Geek

TL;DR

• Our lives can be divided into 3 major activities: Consuming, Communicating, and Creating.
• Only Creating adds value to the world
• Find ways to do more creating

I frequently cite a blog post that describes our lives divided into 3 distinct buckets of activity: consuming, communicating, or creating.[1] Around the same time I read that, I read Leo Babauta’s free ebook about “Focus: a simplicity manifesto in the age of distraction.” The book used similar words, and reinforced this separation with the assertion that creativity can’t happen with all the distractions of consuming and communicating.[2]

Think through your daily activities, and most everything you do can be put in one of following 3 buckets:

• Consuming: All the time we spend reading email, books, social media, watching TV. Eating and driving are forms of consumption too!
• Communicating: At work, it’s meetings, water cooler chat, email, time tracking, etc. At home, it’s time spent talking with loved ones, writing emails to friends, sharing our status and life events, etc.
• Creating: Any activity that reduces entropy in the world, whether our creations are made of words, computer code, sound, paint, wood, etc. This includes any form of teaching.

It’s not just that those activities are distinct, but they also match up to a spectrum of the value we add to the world. Consumption adds nothing, Communication is often necessary to help others with their creation process, and Creation is where we really distinguish ourselves as members of society. It’s not that the first two are inherently wasteful or bad, it’s just that creation is the only way to truly add value.

Another key realization is that same sequence corresponds to required level of energy: Consumption requires no energy (put another way, inertia keeps us on the couch), Communication takes some, but Creating takes “real” energy.

It should be a goal for all of us to increase the amount of time we spending creating, rather than simply consuming.

Some ways I’ve found to move towards that goal:

• Be mindful of which bucket your current activity is in. Knowing that reading Twitter and RSS feeds  is “consumption” is often enough to guilt me into a different activity. [3]
• Use blocks of time for focus, and the longer the interval, pick a more energy-intense task that will create something
• Sometimes consumption is a reward for creation well done. After a good day of creating, it’s OK to surf. On a smaller scale, this is the Pomodoro Technique
• Exercise consumes energy, but (paradoxically?) it also generates energy that can be tapped for more creation.

What do you do to increase time you spend creating?

[1] The point of the post was really as a prediction of why the iPad would be a hit, since it filled a new niche not covered by our desktop computers or mobile phones.

[2] The key for increasing time for creating is focus. The book continues with practical advice for achieving focus with multiple chapters on clearing distractions, simplifying, and focus rituals.

[3] To be honest, I distinguish 2 forms of consumption: 1) mindless reading twitter or Facebook feeds, following rumor blogs, playing solitaire, or watching TV and 2) active reading/watching content that affects my career or project obligations. I can fight the inertia of mindless hyperlink clicking by tell myself I at least I’m consuming something will allow me to create something in the future.

Today is a transition point for me: I officially start a new role tomorrow (same company, different division). What’s key about this  new role is how it fits into my growing awareness of the importance of focus, and how the lack of focus has been a source of stress and unhappiness.

I used to describe myself as a vicious multitasker. I was proud of how many threads I could juggle, with its corresponding appearance of throughput. “Hey, I’ve got 3 instant message conversations going, a voice call, and an active code debug session running.” Those days are gone.

Time and attention are finite resources for all of us, and while time marches on, the only thing we have ultimate control of is what gets our attention. There are constant forces seeking to fragment our attention:

• Multiple projects. When you’ve got multiple active projects assigned by management, you need to keep up appearances that you’re working on all of them. You push each project forward a bit, never sitting down down and making major progress on a single one. In computer terms, it’s called “thrashing”
• Lack of priorities. Multiple projects are made worse when they are all equally important. Many folks won’t admit that there’s a difference between projects being critical and the fact that one of them has to take precedence. The individual is forced to set their own priorities, and 2 individuals may choose differently, which creates conflict.
• Meetings. Since people have different schedules, the “necessary” coordination meetings get scheduled throughout the day. Given multiple projects, you can’t find uninterrupted blocks of time to focus on the doing of the project.

If I were a better note keeper, I’d have a ton of links and quotes on the subject. Here are a few:

• David Allen, author of “Getting Things Done.” Get beyond the surface stuff of efficiency and time management, and he’s really talking about focus and the trust that whatever you are doing at a given moment is the best thing you can be doing.
• Merlin Mann gained fame as a productivity blogger, and has since evolved into a huge advocate for focus and getting to work on the creative process.
• Paul Graham’s classic Maker’s Schedule, Manager’s Schedule sums up the tension between the corporate world and passionate developers.
• The Modern Meeting Standard, a way to bring a form of focus to bad meetings

For kicks, I’ll throw in a picture that made me chuckle. It may not look it, but I was totally having fun, in part because I was focused. This was taken the Minnesota Orchestra Fantasy Camp, where amateur musicians got to perform along side the professionals. I was obviously just counting rests at this point, but, wow, I was in the zone.

I’ve seen various posts that describe what it means to be “on rails” but none that actually address actual physics of it, and why it’s such a perfect metaphor for what Ruby on Rails is.

Why do trains stay on their tracks? Contrary to popular opinion, it’s not the flanges. If it were the flanges, there’d be lots of wear and noise by passing trains. Instead, it’s because treads of the wheels are tapered, and this taper causes the wheel pair to naturally “hunt” for the center of the rails. Richard Feyman explains it quite well on YouTube. Or for even more detail, read about rail adhesion on Wikipedia.

I like to think of the Ruby on Rails framework as the software equivalent of the taper. The conventions that are built into RoR continually drive us back towards making a maintainable application, with good separation of model, view, and controller, test driven development and rich testing frameworks, and the rich ecosystem of gems to avoid reinventing the wheel (pun intended) in common features of applications. Add in some DRY (Don’t Repeat Yourself), and the bevels increase, and the result is like having the two rails turn into a V-groove that your application just rolls smoothly down.

I’ll go even further (and abuse the metaphor) to compare other platforms to the rails. Java is like a railroad without any taper, and it depends on the flanges to stay on track. Java’s flanges include the static typing and the multitude of frameworks that try and help make a better flange (Spring, Struts, Hibernate, J2EE, etc). And oh, does it make a lot of grinding noises!

But thank goodness for the open source community creating all those flanges faster than the Java train can derail, because the .NET world is like a a railroad with the bevels getting wider toward the outside, which is a terribly unstable configuration. (I wish I could find the video I have such a vivid memory seeing as a child (PBS?) showing the comparison of the conical configurations). Sure, really good engineers can create a workable train route, but it’s just too easy for an inexperienced developer to create a train wreck from all the wizards.

RoR is the first framework in my 18+ years of server-side web development that makes me regret all the flanges I had to make in the other frameworks. Thank goodness for those tapers!

All Aboard!

I’ve been trying to pin down some thoughts around the frustration, drama, and friction that seems to arise on workplace projects, and I think almost all of it comes down to the character of the people in the project. We’re often tempted to pin it on impersonal attributes of the project’s context, but it really comes down to the people. Put another way, if the project itself were so terrible, then everyone would think it sucks, but in fact, some people thrive on the project.

Think of a case at work where there’s drama or friction, and then think of some of the key people in the drama, and list 5 adjectives or phrases that best describe each of them. (Google some if good words are escaping you.) Next, list 5 adjectives or phrases about the project or context of the drama.

I bet between those lists, you’ll find incompatibilities in (at least) one of the following ways.

1. 2 opposing traits in 2 key people
2. A person assigned to do tasks incompatible with their own traits
3. The project traits are incompatible with a person’s traits.

For instance, you’ll get friction with an intuitive person working with a metrics-based analyst, a perfectionist on prototype project, or an impatient person on a highly regimented project.

What can be done about it?

First, a tiger can’t change its stripes. It is foolish to try and change the person to fit the situation, and if you do, you’re going to end up with friction from #2. A good manager will naturally assign a detail-oriented person to tie up a multi-faceted project implementation, and not try to pull the details out of the laid-back, wing-it guy. Don’t try to fix the trait with “coaching,” you’re only fooling yourself.

Second, stop looking at character types as being right or wrong. All character types just are, and only get labelled as good or bad when viewed in a particular context. If we look at traits as inherently good or bad, we miss out on assigning people to projects where those traits might be beneficial. For example, even laziness is a virtue, in context.

Finally, work to match projects and people to the traits are compatible.

This may all seem like a big “duh,” but instead of just blaming project problems on the situation or the people in isolation, doesn’t it all come down to putting the wrong people in the wrong situation? On the flip side, when you match up the perfect person with the project, isn’t success nearly guaranteed?

I am motivated by efficiently building quality solutions in a positive team environment. 13 words to sum it all up. If all that happens, it’s like a perpetual motion machine of success.

There are several required elements of a tactical environment to make that happen:

• Work from home. Without commute times, you don’t have to sacrifice the rest of your personal life with the best hours of the day away from the things you love. Also, without distractions of water cooler chat, you can get (and stay) in a productive zone
• Focus. It’s impossible to build quality if you’re fragmented over multiple projects. Get on board with one major project and finish it before going to the next one
• Ruby on Rails. I’ve been developing server-side web solutions for 18 years, and RoR is the first framework that makes me regret the time spent on plumbing. Java allows good separation of responsibilities and quality code, but it seems so verbose compared to the strategy of convention over configuration.
• Mac OSX. A work environment that stays out of your way, with all the power of unix and awesome software.

This week, I’m a happy geek: I was able to persuade my boss to buy me a Mac as my new workstation. And although Apple freshened the notebook line in interval between the order being placed and it actually arriving at my house, I’m very happy with the 17″ MacBook Pro as-is. But the point of this is not to get into the specs or version envy, it’s about why I’m so passionate about it being a Mac.

High end, portable power. 32-bit windows has an upper limit on usable RAM at ~3G. Our development environment isn’t that fat yet, but it’s only getting bigger. Running Eclipse, Tomcat, MS Office, InDesign, MySQL, a couple web browsers, and it’s quickly approaching the point where you start taking a huge performance hit for paging your apps on/off disk.

The only answer is to get into a 64-bit OS to address more memory. I don’t want to fight with 64-bit windows, since I’m not confident in all the compatibility stuff (notably our VPN software). Apple has successfully made the switch between CPU architectures and OS architectures multiple times, so I’m confident there won’t be 64-bit issues with the software. The 17″ MPB can hold 8G, and I plan on using it.

The alternative is Linux, with the windows-specific stuff running in a virtual machine. That environment, however, would be even more “out there” in our company – at least the Mac has some core use the publishing areas.

Better productivity software. Your computer workstation is your main line to getting things done, and it should support you in that by getting out of your way. I haven’t seen anything in the Windows world that can rival the ecosystem around AppleScript and application interoperability that is designed into OS X. Specifically, I plan on becoming a Quicksilver ninja. Quicksilver is to computer productivity as J.S. Bach is to music: every time you sit down with it, you can find a new nuance that makes you appreciate it more. The best resource I’ve found, even though it’s completely dense,  is a PDF enumeration of all the features and plugins.

The other huge productivity win is Spotlight. Built-in full text and file search across the entire machine is like having a private Google. I admit, I never tried Google Desktop,but I’m more confident in Spotlight, since it’s built-in to the OS, and developers are encouraged to make their files compatible with its indexer. Entourage (aka Outlook for Mac) by default extracts copies of all attachments to a cache in your Documents folder, enabling Spotlight to pick them up. I’ve been able find attached file content in single-digit seconds this week, a task I’d often downgrade to a manual filename search, taking at least a minute.

And then there’s OmniFocus, with its rich iPhone integration. I’m just getting started there, so I’ll have to save that for a future post.

I’m also banking on OmniGraffle, an alternative to Visio. A picture is worth a thousand words, and the better looking your picture, the more it’s taken seriously. The defaults in Visio are just ugly, reminiscent of a 80′s flowchart stencil barfing on your paper. OmniGraffle, on the other hand, has gorgeous defaults, tasteful shadows and curves that let you create a picture worthy of your ideas. If the defaults aren’t enough, check out the user contributions at Graffletopia.

Honorable mention:

• UNIX. The power to drop down into a command line and stitch together a series of commands for a complex search or file manipulation is unrivaled. Among geeks, this counts as productivity tools
• Time Machine. How many people backup their laptop regularly, or go to the trouble of buying decent backup software? Now, I just plug in an external disk and forget about it.
• Battery life. How much time is wasted in meetings crawling under the table to a power strip? I’m consciously going to leave power supplies back at the desk: walk in and flip open the lid, ready to start.

I’m not even going to try and debunk the “macs are more expensive” myth. Given all of the above, even if you thought there was a premium for the Apple brand and hardware sexiness, the delta can still be justified by all the other gains.

According to Larry Wall, the first virtue of a programmer is laziness:

The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don’t have to answer so many questions about it

I attribute this virtue to Jeff Hertzberg and Zoë François, authors of Artisan Bread and Five Minutes a Day.  They went through all the tradition and legend of artisan bread baking, questioning everything, and reduced it to its essence, and then documented it for the rest of the world.  

Unlike all those Dummy books that promise to let you learn X in 24 hours, this book lives up to its title.  It really is 5 minutes a day, and you’ll always have amazing bread to go with your meals.

Amy and I are mere beginners in this endeavor, but nothing has come out less than excellent in our tries.  The folks we share with are all suitably impressed, too.  If you don’t have the book, we highly recommend it, and giving it a try.  

As disclosure, a co-worker of mine, Graham, is married to Zoë.  Other folks on the team have tried this and give equal reviews.  It’s fun to hear his stories of the runaway success of the book.  She also has a blog, covering more details and other delectable edibles.

Abstract: A primary disconnect of GTD systems is that they are more interested in the data than the actions.  

As an analogy, let’s pretend you are are tasked with starting a new rocking chair manufacturing company. Would you rather have

1. A pre-designed assembly line that had all the jigs and supplies for the steps involved in building your product, or
2. A Norm Abrams-style workshop (à la New Yankee Workshop) where you have every imaginable high-end tool needed to craft anything out of wood?

Given the background about my use of GTD, now I get to into some new opinions.

I’ve been thinking a lot about personal productivity after getting a blast from the past and the emails it spawned about the persistent poor state of high volume email management.

In object oriented programming terms, GTD is an interface, and it doesn’t come with a reference implementation.  It is exactly this lack of an implementation that leaves people struggling with the use of the system and its habits.  

Each person implements GTD according to their primary constraint.  For instance, if you have a high email volume to balance, you tend to look for a system that deals with your inbox and sorting and categorizing the emails into projects and next actions.  If you’re highly nomadic, you might look for a more physical implementation such as as hipster PDA, so that you’re confident your system is always at hand.

Each of these systems needs to apologize for its underpinnings.  The hipster folks have techniques for dealing with email, and the email folks might make tickler emails for the voicemails that they need to return.  Or maybe they try a grander email system that integrates calendaring and todo items.  But every time you integrate with a pre-existing system or concept, you have to compromise to put your round peg into the square hole.

I contend that even GTD suffers from its underpinnings of trying to be all things to all people.  Because it lacks a system, it has introduced more elements than are necessary.  For instance:

• The weekly review - It’s amazing how good this sounds, but it in practice its job is to patch up all the cracks resulting from a lack of an implementation.  Known as “closing the open loops,” it wouldn’t be necessary if your implementation prevented the loops from getting buried in a folder.  For example, if you have a high volume of next actions, you probably track those items per context.  So each weekly review you have to review the lists to make sure the fact that you haven’t gone to the store this week isn’t blocking the ingredients need for the cake for the party this weekend.
• The project list - If I have faithfully made a folder for each project, why do I need to keep another piece of paper itemizing the folders in my stack?
• Actions vs Projects - Allen defines a project as anything that takes more than one task to complete.  But since large projects aren’t a strict sequence of tasks, you end up with sub-projects.  Suddenly, the scope of an item is obscured,  and you lose the big view of your projects.  ”Should I make a folder for this smaller item?”
• Hard edges –  We’re encouraged to keep hard edges between the categories of things to keep track of.  When the book lists the 7 primary types of things, they’re supposed to stay separate, or you’ll get really confused.  But today’s “waiting for” list is tomorrow’s reference for why the project is late.

I know the book addresses many of these points.  I’m not trying to throw out the whole system, or impugn the value of the habits and flow that GTD promotes.  But I want to build the case for a fresh implementation of something that doesn’t have to apologize for its roots.

Comments are welcome.  I’m actually hoping that this blog can become more of a discussion than just my soap box.