This is a guilty admission of not following my own advice from an earlier post cautioning against never ending task lists. I've been lax with ruthlessly culling my inbound over the past few months and have started to pile up a backlog of interesting tasks, tutorials, books, web docs and side projects. I'll start by rattling off my "active" reading list, which has done nothing but grow since last year and doesn't include the web news and blog posts I read daily.
In the process of reading (% read)
- Design Patterns in Ruby (63%)
- CouchDB the Definitive guide (75%)
- What Technology Wants (28%)
- Linchpin (40%)
And there's much more in my reading queue*.
Besides putting off dedicated reading time, tutorials and side projects are my greatest weakness. I can't resist a good technical walk through, or screen cast. Each and every time I try out a new language, framework or utility I get a mini rush of enthusiasm. The leaner and lighter the interface the better. Natural curiosity combines with wonder when first exploring a new technology, to be followed by understanding and a touch of awe for well crafted designs. There are a handful of tutorials I'm in the midst of working through.
Tutorials I haven't completed but would like to
- Ruby on Rails Tutorial, Learn Rails by Example - it's also a book (20%)
- jQuery Mobile + CouchDB Part 1-6 (1 read)
- Rails for Zombies (couple of labs)
Last and certainly not least on my task list are side projects. I split time for side projects between passive (following/reading/learning) and active (experimentation, stuff I authored or contribute to). On the passive front I follow a couple of dozen projects on github, which feeds my information addiction with commits, updates and large redesigns. Even a single active project can take significant time to keep track of and understand. But those are mainly passive interests that I can ignore when short on time. My own projects require tweaks when improvements spring to mind as well as maintenance. Third party API changes require code alterations and updates (ie Twitter going OAuth, and likely streaming only, Heroku shifting to Badious Bamboo). There's nothing quite like building your own web app and growing it from ideas into a reliable utility.
Update: based on a request for how to improve focus and results from HackerNews User RiderOfGiraffes I've added my past history with task lists
One of the problems I've had with various to do list hacks is that task priority and completion changed over the life of the list. In addition coordinating group tasks doesn't have a natural fit with planning personal activities.
Large tasks morphed over time into long term goals, and never left the list. Actually I preferred those because they aided navigating smaller decisions on how to spend my time, without having a discrete blob for each task. "Is this task helping me achieve my long term goal, if so how and how much?" More on this later (the text file task list).
Quick history of my relationship to task lists:
When I started my first push towards a functioning product (and what I hoped would be a real company) I used p2, a wordpress blog theme for coordinating group activity.
I combined that with emails and filters by recipient to keep track of ideas that were plausible and consistent with the driving product idea (relevant ads based on social streams).
Over time my email usage as a task list grew into many different tabs (gmail) and information gathering/interests intermixed with project tasks (bad idea). I became bogged down with what I thought at the time were relevant tutorials, docs, and ideas but later proved to be of limited value or wild goose chases down implausible technical paths.
My technical cofounder (he had four years of web development under his belt in 2009, I had a few months) coordinated our product and coding activities with lighthouse milestones and tickets. Those worked fine for well defined objectives, but ended up decaying too slowly based on our understanding of project direction. Eventually we abandoned the lighthouse ticket approach to email coordination and screen sharing.
At that point I relied on a simple text file to keep track of my top handful of project priorities (and nothing else) and worked through them one a time. I could rearrange the order on the fly as specific tasks became more important (overhauling an ad widget's design, redesigning the interface to be more attractive to visitors vs. hosts). Those tasks morphed into priorities that served as a filter for irrelevant vs focused and necessary actions.
In our busiest periods (late 2009/early 2010) email and text files weren't enough. Even priority lists felt inadequate and I stopped regularly wrestling with the lists. At that point I naturally realized the idea, when it comes to startups lists there can be only one. One thing has to stand apart and be doggedly pursued until it's finished and proven valuable, or discarded and proven a false alarm or too difficult to handle with current resources. http://victusfate.github.io/victusspiritus/uncategorized/2010/07/18/when-it-comes-to-startup-tasks-there-can-be-only-one/
We tried several different ideas and Tyler has become a formidable web hacker, while I've gained some technical chops (I've coded algorithms/sims in c++ for 15 years but only recently added web development) and continue to refine my product focus and understanding of market needs. Unfortunately our product ideas and implementations didn't pan out. After actively pushing for a year without results we parted ways and are still friends.
At the end of 2010 I took a break from web development but came back to it with the new year. Since then my personal task list (and backlog of desired activities) has become sloppy.
*= my to read list
Just opened the cover/skimmed, but I'd love to read
- HTML5 Up and Running
- Learning OpenCV (image processing goodness for work)
- The Innovator's Dilemma
- Viral Loop
- I live in the future & here's how it works
- Cognitive Surplus
- The Age of Spiritual Machines
- Zen Unicorn
- An Inquiry into the nature and causes of the wealth of nations
- The critique of practical reason