Guests

Michael Buffington: iGTD + Quicksilver + subversion

Merlin — Thu, 28 Jun 2007 07:00:53 -0400

This is the second entry in a multipart series about my recent obsessive love affair with GTD, the iGTD application and Quicksilver.

In the last entry I put the emphasis on getting my tasks written down quickly and out of my focus into a system I could trust. I could choose to spend some time later to review my tasks and do what I like to call "iGTD gardening", where I check up on all my projects and do a bit of weeding of duplicate or irrelevant tasks, and fortify those tasks with whatever information comes to mind as I'm looking at them.

Since I'm now in the habit of pushing new tasks to iGTD and immediately forgetting about them I have the refreshing ability to work on a task without ever thinking about anything else. iGTD then becomes my set of instructions to follow when I need guidance, and if I've tended my task garden well, it's a rich set of instructions with a lot of tedious thinking already finished.

This system works out alarmingly well until you're possessed by SSD (severe stupidity disorder) and delete your iGTD database without even a whiff of lingering vapors. Immediately you'll be consumed by a profound and unshakable dread as you realize your tether has been severed from the mother ship and you begin to drift into outer space, your Tang to be divided up amongst your colleagues (even the ones you loathe).

Luckily for most of us, iGTD makes database backups upon starting up the iGTD app and for a couple of other events, and luckier still, most of us don't suffer from SSD very often.

But I often do, and don't leave anything to chance.

Rather than risk losing my entire brain to an episode of SSD I employ a SMP (scheme of massive paranoia). It might seem quite heavy handed, but I send a backup of my iGTD data to a subversion repository whenever the iGTD database changes. In a nutshell, it means I have a comprehensive history of every save ever done to my iGTD database, and am nearly assured that I'll be able to save myself from myself with only the smallest amount of data loss.

Now I'll be the first to admit that what we're about to look at is a bit Rube-Goldberg-esque, and I'll admit there's a certain joy in that as well.

A few things to know before we move on:

I'm doing this all on Tiger, which means I have both Ruby and sqlite3 installed out of the box.
Your paths to both Ruby and sqlite3 might differ from mine.
This code likely has bugs. I whipped it up in a few hours.

Also, worth noting - I'll be adding to this body of code as I move on with more blog posts about iGTD. What may look a bit like an empty shell now will get some more meat as we go along.

And finally (I promise), all the code I talk about in this series will be downloadable at some point.

Create some Ruby!

Create a file called iGTD.rb in /usr/local/lib/ruby (or /opt/local/lib/ruby if you're using the Macports version of Ruby like me).

Write the following code:

class IGtd

    def self.capture(string)

        i = IGtd.new

        i.push_to_igtd(string)

        puts string

    end

def push_to_igtd(string)    
    `/usr/local/bin/sendtoigtd "#{string}"`  
end


end

That'll start off our iGtd library with something basic. It seems totally superfluous when you think about it, but remember, we'll be adding to this at a later date.

The newest version of iGTD (v. 1.4.5) comes with a command line utility that allows you to pass your task along the same way you push tasks into iGTD through the Quicksilver plugin. The above code simply wraps some Ruby around that command, executing it when we call it, which we'll come back to in a moment.

Now we're going to take advantage of a Quicksilver feature that you might not see documented many places - you can pass text to Ruby scripts saved as action in ~/Library/Application Support/Quicksilver/Actions. Up until recently I assumed you could only have AppleScript actions, but that's not the case.

Let's see some of that Action in action. Create a file called gtd.rb in ~/Library/Application Support/Quicksilver/Actions that looks like this:



!/opt/local/bin/ruby

require 'iGTD'
IGtd.capture ARGV.join(" ")

This script takes whatever commands are passed in, joins them back up as a single string, and hands them to the IGtd.capture method we wrote above. Note that we join the string back up because Ruby splits up command line arguments into an array wherever it sees a space. So we simply reverse that process by adding the spaces back in.

Make sure you make the file executable. chmod ug+x gtd.rb should do the trick.

Once that's saved you should be able to invoke Quicksilver, press period to invoke text mode, hit tab, then type gtd. Your gtd Ruby script should show up in the list (if it doesn't you might need to restart Quicksilver [CTRL-CMD-Q]).

Now, despite the fact that you're using your own Ruby based action instead of using the iGTD Quicksilver plugin, your task will end up in iGTD.

Neat, but we're missing the paranoia. Let's add subversion commits into the mix.

At this point I have to assume that you've managed to get your iGTD.sql file located at ~/Library/Application Support/iGTD into a subversion repository, hopefully offsite. I'm gambling on the fact that you have some knowledge of subversion if you have any desire to do this at all.

Because the iGTD.sql file is binary, we want to dump it as raw text to be a bit more efficient with subversion. subversion only keeps track of differences between revisions with ASCII files, but keeps entire copies of binary files (which might not seem like much, but for a file that's in the 60-80k range, 6000 changes can turn into a 500MB subversion repository).

Having the iGTD.sql as an ASCII dump helps increase portability as well. You can rely on simple text editors to see your data with an ASCII dump, and in the worst scenarios, viewing raw SQL statements can be quite comforting if the alternative is viewing nothing at all.

Let's add the following method to our iGTD library (note that when you see a ↵ symbol that what should normally be on a single line is wrapping to fit the page - make sure you fix those lines if you're copying and pasting):

class IGtd
    def self.capture(string)
        i = IGtd.new
        i.push_to_igtd(string)
        i.commit_to_svn
        puts string
    end

def push_to_igtd(string)    
    `/usr/local/bin/sendtoigtd "#{string}"`
end

def commit_to_svn
# tidy up some of the paths
igtd_data_path = "/Users/mike/Library/Application Support/iGTD"
svn_path = "/opt/local/bin"
sqlite_path = "/usr/bin"

# dump the sqlite db to an ascii backup file
`#{sqlite_path}/sqlite3 "#{igtd_data_path}/iGTD.sql" &crarr;
    .dump &gt; "#{igtd_data_path}/iGTD.sql.automatic.bak"`

# commit it to svn
commit_msg = `#{svn_path}/svn ci "#{igtd_data_path}/  &crarr;
  iGTD.sql.automatic.bak" -m "Automatic backup of  &crarr;
  iGTD.sql backup file done: #{Time.now}";`

# if no changes were made, svn won't output anything - it'd &crarr;
be nice to know that we at least tried.

if commit_msg == ""
  commit_msg = "Nothing to commit, therefore no svn commit was done."      
end

# now send the message to growl
`echo "#{commit_msg}" | /usr/local/bin/growlnotify`    
return commit_msg


end
end

Now, whenever you push tasks from Quicksilver to iGTD through our gtd.rb action, subversion will commit the changes. I've added the luxury of being notified by Growl when the commit happens. Pay special attention to the paths in the script and make sure you're pointing to the proper places.

With this in place, not only are my backups effortless, but they're comprehensive. And because my subversion repository is on a remote server, I can reconstruct my task list as long as I have a computer and an internet connection. Given enough time to think about it, I'd probably get paranoid about my subversion server keeling over too. Entertaining those thoughts to their final conclusion would require I hire stone carvers and buy a large granite mountain to chisel my lists, so at this point I'm content with the offsite backup.

This extreme paranoia with an admittedly heavy handed solution helps increase my trust level with iGTD, but it also opens the door to doing other automatic tasks whenever I enter a task through my custom gtd.rb file.

In the next entry in this series I'll show you how you can enter a task in iGTD once and have it travel to both Stikkit and Basecamp with a few additions to the iGTD Ruby library discussed here, and even grab new tasks from Stikkit.

Following that entry will be something I consider quite special - getting tasks into iGTD from your mobile phone through SMS. Assume the bullfighter's stance and repeat after me: ¡muy emocionante!

About the Author

Michael Buffington - A serial entrepreneur and creative technological consultant, Buffington most recently served as the Community Advocate for Values of N, makers of Stikkit and iwantsandy.com. He's now secretly building games for the masses.

”Michael Buffington: iGTD + Quicksilver + subversion” was written by Merlin Mann for 43Folders.com and was originally posted on June 28, 2007. Except as noted, it's ©2010 Merlin Mann and licensed for reuse under CC BY-NC-ND 3.0. "Why a footer?"

DavidCo's Robert Peake on "Getting Software Done" (part 2)

Merlin — Wed, 18 Oct 2006 08:20:24 -0400

This is the second of a two-part article by Robert Peake, CTO of the David Allen Company. Be sure to start with yesterday's first part, "Why GTD Matters To Programmers."

Part II: GTD and Extreme Programming

by Robert Peake, David Allen Company

I have to admit that I'm not a perfect adopter of Extreme Programming. We don't program in pairs, for example -- quite the opposite, our coders are flung far and wide, tethered together only by a broadband connection. However, as much as GTD is "advanced common sense", so to my mind is Extreme Programming a form of "best practices on steroids" -- and for this reason, there are not only many parallels, but great crossover when it comes to managing programming projects.

Software didn't used to have to be very adaptable. Mainframe software systems were only slightly less mutable than the hardware they ran on, and dependability -- not responsiveness, new features, or interoperation with some other cool, new application -- was key. Along came the internet, and the ability to patch and change software online. All that changed.

Likewise, while even forty years ago dependability seemed to exist both in terms of job definition and job security, adapting to change may well be the single most important trait of the knowledge worker today. And increasingly, the ability to manage large volumes of information, focusing on what's important and ignoring the dross, has become key. For this reason, a few critical concepts in programming apply to getting software done with maximum efficiency and also suggest some important directions for any kind of project -- they are: regression testing, refactoring, and documentation.

Regression testing is, quite simply, spelling out a list of tests to perform so that you can verify that what you have created works as expected. The "regression" part of it is that you often want to run the same rudimentary tests you ran in the beginning of the project much later in the evolution of the product. This is to make sure you didn't break something. Regression testing goes hand in hand with documentation, which stems from the same inspiration: describing how the thing should work. Once you have described how the thing should work, and made tests you can perform later to prove it, you need to make sure that documentation exists within the source code. In our case, we use automatic tools to pull out the documentation we mix in with our source code, and have created for ourselves an automatically updated manual of how various functions and parts of our system work. We even set up shortcuts so that with a couple keystrokes, we can access documentation for not only the core language, but our own collection of application-specific functions, right from within the source code we are working on at the moment. The result? Six months after writing something critical, I don't have to go crawling back through file after file of source code to figure out how to use that particular building block or tool.

All of this relates to GTD when you bring in the concept of outcome-based thinking. Every time you pick up an artifact of your own thinking (be it a scribble on a note-taker wallet page or a mind map on butcher paper) and then decide that what you've really notated for yourself is a project, the very next question is: what is the desired outcome? In other words, how will I know I've finished this project? What will be the result? Likewise, all the activities in Extreme Programming such as gathering user stories, writing regression tests for each unit and component of the software, and documenting the intended behavior inside the code itself so someone else can later understand what you were trying to do -- embody outcome-oriented thinking for software. Jumping to the end first works consistently and well to line up your thinking in the right direction. Getting that thinking captured appropriately into your trusted system -- and not over-thinking into all the possible ramifications and rabbit trails that will likely only get blown away when new real-world input arrives -- is key to staying agile, flexible, and dynamic.

Another key to programming in an agile way is refactoring. This is going back to what you've written -- not to add features or fix bugs per se, but to clean up your thinking and make it line up with your new understanding of the project. The truth is that thinking takes time, and it evolves over time. So, revisiting the code on a regular basis, purely for the sake of shoring things up and reworking things into a more effective paradigm, may seem like a lateral shift on the surface -- but makes a huge difference in the overall maintainability of the code. Likewise, the maintainability of your life and your trusted system that runs it can also be equated to how often you perform a weekly review. The weekly review is refactoring for life -- a time to take stock, reevaluate your understanding of and progress on projects, make sure all actions are tied to projects and projects to actions, and to scrub out all the stuff that's been either completed or rendered irrelevant by time (sort of like getting rid of the variables you thought you'd need in your code but didn't -- preventing memory leaks and tightening things up for later). Refactoring is as important in life as it is in software.

We used these three branches of Extreme Programming to great success in building GTD Connect. One other critical technique or skill involved was being able to flip from a very high-level creative brainstorming session with our senior people into sussing out the specific outcomes that would demonstrate we've done our job on the technology side. None of this precluded writing up documents spelling out our understanding of what's important and what's nice to have, the timing involved, as well as some of the mechanics of what we are doing and the business side of how much it would cost. But ultimately, being able to differentiate between and translate from the right-brain mind mapping sessions into left-brain outcomes led to just enough of a specification to get our coders excited. Trusting this process gives you the freedom to be wildly creative in the brainstorming session (because you're not nailing anything down yet). It also empowers programmers with the flexibility to find a smart, dependable, architecturally sound approach to solving the problem on the other end -- because when you feed programmers outcomes rather than dictating precise specifications in pseudo-code, you give them the freedom to work within the context of the whole system to come up with the best solution. And you leave room for constructive, creative surprises -- the unexpected killer features that can only thrive in a healthy, outcome-oriented relationship.

One of the tenets of Extreme Programming Merlin mentioned in our panel is the idea that, "You ain't gonna need it." While I never overtly said this to The David in our sessions, the spirit of this approach is something that has pervaded the process of leaning into the great (and so far highly successful) experiment of launching Connect. That spirit of the idea is to build to a need, rather than a nice idea. In balance with this, we also tried to cast our net wide enough in terms of variety of features so that we can test and see what people gravitate toward, and what might fall away. This natural process of meeting customer feature demand on its own terms is highly analogous to the GTD approach of getting through each work day on its own terms, using action lists tied to projects rather than other forms of "best laid plans."

A big key to the mechanics of getting a project as big as Connect done (and then maintaining and improving it incrementally) has been a shared project list accessible by all our developers. First of all, we trust our people. I have never seen the approach of trying to enforce people's job constraints through software permissions really work when it comes to project management. Instead, anyone can add, edit or mark a project complete in our system. This means that our development people can keep their complete project inventory in a shared format and can edit projects assigned by others to keep notes and add important details. We use a Lotus Notes database for this, but this approach could also be easily implemented via one of many web-based applications or even a shared whiteboard if everyone works in the same room.

Another key with all of this, and a somewhat revolutionary approach, is that we don't track bugs and feature requests in separate places. It all has to get done anyway. And because maintaining a comprehensive inventory of everything that needs to get done in one place, accessible by all the relevant people, we can very quickly re-calibrate to focus on what's critical. Sometimes that's a bug. Sometimes it's a great new feature. Either way, we use the system to support us like a giant radar screen, and good communication in person, by phone, email, and IM to determine what's critical and go after it. So far, it's worked great to keep us engaged with our members and our own staff and be responsive to their input.

Connect has been a lot of fun to build, and it's great to watch it start to really thrive. Hopefully this little peek under the hood has got your own gears turning about software development with GTD and perhaps even other areas of your work or life where these analogies hold. If you're feeling particularly geeky, more platform-specific details on the best practices we drew from when pulling Connect together are here.

And if any of this has rung your bell and you want to chat, please drop me a line at robert at davidco dot com, or catch me on the forums. Until next time, happy coding, happy GTD'ing, and be well.

Robert Peake used to teach programming languages to computer science students at Berkeley before earning his degree in poetry. These days he is the CTO of The David Allen Company, where he reads, writes, and thinks about many things in many languages.

Update 2006-10-18 10:05:52 - For your convenience, here's an easy-to-print HTML version of both of Robert's posts.

”DavidCo's Robert Peake on "Getting Software Done" (part 2)” was written by Merlin Mann for 43Folders.com and was originally posted on October 18, 2006. Except as noted, it's ©2010 Merlin Mann and licensed for reuse under CC BY-NC-ND 3.0. "Why a footer?"

Guest Post: DavidCo's Robert Peake on "Getting Software Done" (part 1)

Merlin — Tue, 17 Oct 2006 08:15:01 -0400

Robert Peake is the brainiac CTO for the David Allen Company (a/k/a, "DavidCo"). I first met Robert when I was down in Ojai a few weeks ago to record some stuff with The David, including our Productive Talk podcasts and that TechGTD panel we did with Robert and Eric Mack.

Robert really impressed me with his humor, his insight, and his mad Macintosh skillz. Also -- off the record -- I happen to think Robert's probably the most articulate evangelist for geek GTD I've ever met. He really gets both pieces so well that, of course, I demanded he write an article for 43F, right on the spot. He was kind enough to play along, and flipped around this terrific piece in record time.

As he covers in this series, a lot of Robert's time over the past few months has been spent putting together the GTD Connect membership program, as well as making sure all the company's lights stay on from a technology standpoint. Since I know a lot 43F readers share Robert and my interest in GTD and programming, I'm sure you'll dig hearing from him. He successfully pulls together some pieces I've had floating around in my own head, and I thank him much for sharing this.

[Note: Part 2 of Robert's article, entitled "GTD and Extreme Programming," appears Wednesday on 43 Folders.]

Getting Software Done

by Robert Peake, David Allen Company

Since launching GTD Connect, we have gotten a lot of great feedback not only on the content, but on the technical underpinnings of the system we built to deliver the audio, video, forums, podcasts, and other goodies on the site. What a lot of people may not realize is that, to my mind, a lot of the elegance expressed in the technology that drives Connect stems from the fact that we implement and use the GTD methodology in our software development process. We really do "eat our own dog food" at DavidCo, and I'm convinced that necessarily translates to a more positive user experience overall in every product we produce, and especially software. A lot of people also don't realize how highly relevant GTD is to the software development industry specifically, and how many interesting parallels there are between software best practices and workflow best practices (i.e. GTD).

So, I'd like to run through some of the relationships between GTD and developing software well, using the past eighteen months or so of building up GTD Connect from concept to reality. I'll use our experience building Connect as a kind of case study to ground some of the concepts and ideas with practical examples. Having seen a range of tactics deployed in software development by other companies, I can definitely say that our outcome-oriented, GTD-inspired approach to building out the web applications that make GTD Connect work has been far and away the most functional and positive approach I've encountered so far. So, if any of these tips and tactics strike a chord with you, I encourage you to consider looking at how you might fold these concepts into your own project management -- whether or not the project is software.

Part I: Why GTD Matters To Programmers

The first myth to dispel is that programmers don't need GTD. The Orwellian (or perhaps even Kafkaesque) world in which a programmer is nothing more than a human vessel for translating detailed design specifications into lines of code -- left to right, top to bottom -- is nothing more than a nightmare. The waking reality is that programmers in functional development companies make complex decisions and juggle multiple priorities constantly. And don't even get me started on interruptions. I have seen so much time, energy, and cash sunk into complex Gantt charts that get obliterated with the flick of a CEO's finger. Any company that thinks A,B,C priority codes and strap-on horse blinders for their programmers are effective means to stay on the leading edge of software is headed for a rude awakening.

Permit me, if you will, to borrow a few pages from computer science for a minute to illustrate the power of GTD in the programmer's world. The term "serialization" can refer to a process of basically freeze-drying data into a format that can later be reconstituted and played with elsewhere in the program. It's a very powerful technique for maintaining the state of the data, intact, as you transport it to another location (physically, virtually, whatever). Using a trusted system with the GTD methodology allows you to serialize your work life -- to freeze dry it in a readable format (your system, be that a Hipster PDA, a plain text file, or a fancy graphical task manager). By effectively bookmarking your complete working state just enough so that you can pick back up where you left off, GTD actually allows you to deal with the boss that comes in every five minutes to get an update on your TPS report cover sheet. The promise of a trusted GTD system is the promise of never having to think twice about what you were doing; just as the promise of serializing data is that you don't have to re-instantiate or re-calculate the structure you serialized. Store it, retrieve it, add water, and poof -- you're back up and running without any wasted cycles.

You can also handle massive changes in the architecture of the software you are working on -- whether that's coming from inside your company or via a customer -- because the beauty of the GTD system is that it deals with ambiguity in real time. The analogy I use here is data search trees. If you imagine a tree with many branches, the depth-first approach to searching the tree would be to go down to the end of every branch and back again. The breadth-first approach just involves checking out all the junctures on one level, then the next. GTD is a breadth-first approach to handling your life. Rather than trying to run down all the branches to the end, using GTD means thinking just as far ahead as you need to think in terms of your actions, and no further. So when things change in the real world, as they invariably do, you don't have to spend hours re-drawing the Gantt chart -- instead, you are already at the appropriate juncture, and can instantly re-calibrate and change course to take the next most appropriate path. This means you are constantly thinking at the level where the surprises really happen, rather than building out into the future on a potential house of cards. For risk mitigation, as well as remaining in step with an evolving understanding of complex projects, this is huge.

GTD in this way also provides the ultimate "safety net" for making sure stuff doesn't slip through the cracks. Sure, the act of programming in itself is highly linear: you run down the path until you have satisfied your test cases, then you move on to the next thing. However, in addition to bookmarking your progress along the path so that you can get right back to what's important after an interruption, GTD also gives you a complete, trusted inventory of all of the very next steps along all possible paths. Combined with an overall strategy (obviously), this means you can program with greater confidence and peace of mind -- can run down the trail knowing it is the perfect trail for you to be running down at this moment -- because you have scanned all the other options first, and know this course to be the best. Life, especially the life of a developer, is an open-ended, unknown tree. And the breadth-first approach of GTD is necessarily the most efficient option for traversing that tree.

For the old-timers in the crowd, a much cruder form of outputting data from the running program in a storable format is the famous core dump. So named because originally magnetic cores stored the ones and zeroes involved, this process is the software equivalent of downloading your entire brain into a file. Wouldn't that be nice? The "mind sweep" component of GTD is just that, and in fact David has often referred to it as a kind of core dump for "psychic RAM." This is how you periodically check in with your own brain to see what is holding your attention, and get it out of there to look at. This is how you assemble those lists of possibilities (projects and next actions) that serve as the safety net to give you confidence that what you are doing is the right thing to do, and combined with the two-minute rule and next-action thinking, gives you that freeze-dried bookmark of your working state so you can seamlessly pick up where you left off when (not if) you get interrupted.

Clearly, programmers need GTD more than Jolt or Domino's. And the people managing programmers, responsible for architecture on the front end and quality assurance on the other side, need it just as much. Permit me to explain...

[Note: Part 2 of Robert's article, entitled "GTD and Extreme Programming," appears Wednesday on 43 Folders.]

Update 2006-10-18 10:05:52 - For your convenience, here's an easy-to-print HTML version of both of Robert's posts.

”Guest Post: DavidCo's Robert Peake on "Getting Software Done" (part 1)” was written by Merlin Mann for 43Folders.com and was originally posted on October 17, 2006. Except as noted, it's ©2010 Merlin Mann and licensed for reuse under CC BY-NC-ND 3.0. "Why a footer?"

Guest Review: Fraser Speirs on "Time Management for System Administrators"

Merlin — Mon, 28 Aug 2006 05:40:19 -0400

Review by Fraser Speirs

Time Management
for System Administrators
by Thomas A.Limoncelli

At the end of 2004, Merlin blogged about possible extensions or specialisations of Getting Things Done for specific constituencies, such as programmers, students or parents. Thomas A. Limoncelli’s book Time Management for System Administrators is perhaps the first example I’ve seen of a book which advocates a GTD-style workflow with some modifications specific to the system administration “lifestyle”.

Book Structure

The book is laid out under the following thirteen chapter titles:

Time Management Principles
Focus Versus Interruptions
Routines
The Cycle System
The Cycle System: To Do Lists and Schedules
The Cycle System: Calendar Management
The Cycle System: Life Goals
Prioritisation
Stress Management
Email Management
Eliminating Time Wasters
Documentation
Automation

The core chapters for GTDers to think about are really chapters 4 through 8 and 13. The material about maintaining focus, handling email and managing stress will be familiar to regular readers of 43 Folders.

Although Time Management for System Administrators is not a simple modifier on GTD, in the sense that the author doesn’t explicitly reference GTD until the epilogue, much of the structure of Limoncelli’s suggested workflow will be recognisable to those familiar with David Allen’s book. Although Limoncelli doesn’t refer to GTD in the body of his work, it’s hard to avoid certain very obvious parallels such as the analogy of one’s memory as “RAM” (c.f. Allen’s “psychic RAM”) and the strategy of “Delegate, Record or Do” (which sounds much like Allen’s “Do, Defer or Delegate” in another order).

However, it would be unfair to dismiss Time Management for System Administrators as a GTD knockoff. It’s certainly not. One area in which I have personally found GTD to be weak is that of helping me decide ‘what to do next’. Certainly, David Allen does have some advice on that matter, but I always found it a little difficult to relate to my workplace. Limoncelli’s Cycle System is, I believe, a very strong contribution to filling that gap in GTD.

The Cycle System

Limoncelli’s Cycle system has seven steps:

Create your day’s schedule
Create your day’s to-do list
Prioritise and reschedule
Actually do the work
Finish the day
Leave the office
Repeat

Let’s break that down a little.

Create Your Schedule

Creating your schedule is as simple as taking your appointments calendar and blocking out the times in which you are committed to be somewhere or do something. For most people in Systems Administration this means meetings or presentations but, for example for teachers, it might be class times. Having created the schedule, you now have a rough idea of the remaining hours left to progress your projects.

In GTD parlance, this is your hard landscape.

Create your To-Do List

Many systems administrators use a ticketing system to track user requests (and those who don’t ought to!), so that can be considered a master list of to-dos. In a Sysadmin’s workflow, it’s not unreasonable to use the request tracker as the canonical list of everything that needs done.

The Cycle System suggests that you take a number of items from the master list (and from your email, voicemail, etc.) and write them down for today. Beside each item, estimate the duration of the task. You now have some idea of the time you need to complete these tasks. It is unlikely that this time will be shorter than the time available, so this leads us to prioritisation and rescheduling.

David Allen warns against creating daily to-do lists as their incompletion can be demoralising. Limoncelli argues that interruptions and associated slippage is inevitable for the busy System Administrator and should not be considered representative of failure.

Prioritise and reschedule

The Cycle System provides for three priorities, defined very pragmatically:

A: “The deadline is today”
B: “The deadline is soon”
C: “Everything else”

When you find yourself overflowing the available time for today’s schedule there is a simple rule for rescheduling:

Move all “C” tasks to tomorrow.
Use one of several suggested strategies to make the rest fit.

The suggested strategies include:

Decompose tasks into smaller chunks and schedule them individually. For example, unpack a server one day and check that all the parts are there. Next day, rack it up. Next day, assign IP addresses and install it. This is very next action-ish to the seasoned GTDer.
Find a way to narrow the scope of a large, high-priority task. The example given is installing a user’s new machine. Instead of building it to perfection, install the OS and create user accounts, then leave the user to polish it up to their liking. This only works with certain classes of user!
Delegate - a principle familiar to GTD fans.
Ask your boss. This can sometimes help make your boss aware of cross-department support issues that can be resolved at a level higher than the individual System Administrator.
Delay an appointment or meeting. If you have a large task that requires real ‘in-the-zone’ focus, it might be appropriate to re-jig your hard landscape to allow time for that task.

Do The Work

Most 43 Folders readers will have their own strategies for avoiding interruption and distraction, but Limoncelli provides two tactics for the Systems Administrator that I found novel:

Create a “Mutual Interruption Shield” - if you share an office, have one person take all the interruptions in the morning and have the other take the afternoon shift.<
Structure your office or group seating arrangement such that the junior or tier-1 support people are the first people that a visitor will see or walk by on entering. This enables those people to protect the more senior people from interruption by visitors.

Finish The Day

Come the end of the day, if you haven’t finished your tasks, it’s necessary to manage that situation. This feels a little like a GTD weekly review in miniature. The recommendation is to take 30 minutes and the end of the day. The hard but important part is handling the unfinished Priority-A (“The deadline is today”) tasks - Limoncelli suggests a phone call to the user and the development of a contingency plan.

For other tasks, the Cycle System suggests that they’re simply pushed to the next day’s cycle. Presumably, although it isn’t stated in the book, tasks which are blocked should go into some kind of ‘waiting’ state. GTD has this made explicit in that some projects or actions are “waiting for” some external event or input.

Other Parts

Chapters 9, 10 and 12 talk about Stress Management, Email Management and Documentation. All of this material will be more than familiar to GTDers and general life-hackers.

Automation

Chapter 13 deals with the question of when to automate processes. Automation, when correctly applied, is a huge win for System Administrators. Limoncelli decomposes the decision about when to automate by dividing tasks into ‘simple’ and ‘hard’, and their frequency into ‘once’ and ‘often’.

The argument is that tasks which are either frequent but simple or one-off but hard should be automated. One-off simple tasks should be done manually and frequent hard tasks are often best served by some off-the-shelf or bespoke software package.

In general time-management processes, automation can be powerful. Imagine, for example, going back to the days when you couldn’t sync your phone’s address book with your computer’s. Automation allows you to:

Do something frequently and consistently (e.g. check that your phone matches your computer)
Reduce the need to remember those rare-but-complex steps of operations (e.g. remember how to add a contact in your computer and your phone)
Scale to a much higher level (e.g. tapping in 10 phone numbers is OK, 200 much less so)
Avoid errors

Whilst the automation examples in the book are probably not broadly applicable outside the world of System Administrators, I found the ‘when to automate’ decision matrix to be a simple but enlightening tool for clarifying my thinking on the matter.

Summary

Although Time Management for System Administrators is intended to stand on its own, anyone familiar with GTD will immediately see parallels and wonder if the Cycle System is intended as a replacement for GTD. I don’t think it’s complete enough to do so. I do think that, for some work situations (and certainly for the System Administration ‘lifestyle’), the Cycle System is almost a drop-in replacement for David Allen’s advice on ‘what to do next’.

I work as a Systems Administrator, and one of the difficulties I often faced, despite implementing GTD, was trying to decide which project was important enough to do next. Limoncelli’s Cycle System nicely plugs that gap in GTD for this particular audience.

David Allen’s idea of the Next Action is powerful, but can often lead to an approach which is more tactical than strategic. The Cycle System is similarly tactical. If there’s a criticism to be made of the workflow described in Time Management for System Administrators, it is this: sometimes in your decision making, you need to give weight to the question of the long-term tactical advantage that a project will deliver. For example, if you’re getting a lot of calls about a small but niggling problem, it’s probably worth promoting that to a higher priority, even if it’s not immediately deadline-driven.

Time Management for System Administrators is an easy and quick read, particularly for those already sensitive to the issues involved in productivity and time management. It’s certainly recommended for System Administrators; others may find it useful too.

Buy Time Management for System Administrators at Amazon.com »

About the Author

Fraser Speirs is a Software Engineer and Educator. He runs Connected Flow a shareware producing apps for Mac OS X, including the popular iPhoto plugin, FlickrExport. Fraser also teaches Computing Studies and was formerly involved in setting up one of the first production Computing Grids in Scotland, as part of the Worldwide LHC Computing Grid project at CERN.

”Guest Review: Fraser Speirs on "Time Management for System Administrators"” was written by Merlin Mann for 43Folders.com and was originally posted on August 28, 2006. Except as noted, it's ©2010 Merlin Mann and licensed for reuse under CC BY-NC-ND 3.0. "Why a footer?"

Guest post: Scott Andrew on "Productivity for the Practicing Musician"

Merlin — Mon, 07 Nov 2005 05:51:03 -0500

Some time back, mathowie poked me about talking to our pal, Scott Andrew, about some of the productivity mojo he uses to keep his one-man acoustic pop army in line. Turns out that, in addition to being a terrific singer/songwriter, Scott’s got a mature system for booking gigs, promoting his work, and maintaining a lively relationship with his many fans.

Although there are tips here that will be useful to everybody (keep it simple; fear not lofi; provide great customer service), the musicians, artists, and other performers out there will most especially learn from what Scott’s got going on; as my friend Sean is fond of saying (in a booming, fakey showbiz-guy voice): "It's not music 'friend'; it's music business!"

Productivity for the Practicing Musician

by Scott Andrew

When Merlin approached me about writing a sort of “Getting Music Done” piece, I initially thought: buh? I’m probably the worst model for artistic productivity. After mulling it over, it occurred to me that I’m probably a very typical model. I have a day job. I have rent. I write songs on a used thriftstore guitar and record them when I can scrape enough gig money together. I spend my creative life in that emotional DMZ between self-assured, passionate DIY ferocity and vague, nagging career dissatisfaction. In other words, I’m just like most aspiring musicians. Perfect! So don’t please look on this article as advice from someone who’s “been there” — I’m still getting there.

I once read a rant by a punk musician who complained that if he had the time and ability to do all the stuff needed for a rewarding music career, he wouldn’t need a record deal. Well, yes. The unsexy truth is that some days you’ll feel more like a Post Office than a rock star. This pisses off some people who’d rather be working on, like, music, instead of bookings or publicity. But that’s okay, because the worst that can happen is: nothing happens. Eventually you get tired of nothing happening, and you resign yourself to the “business” side of the music business. Sigh.

Tools

So let’s say you’ve been woodshedding away and you’re finally ready to take your garage-rock masterpiece on the road. Once I made the jump from the bedroom to live music circuit, I found most of my activities consisted of searching for new opportunities and staying on top of existing ones. I call the former “filling the funnel,” which is any activity that gets me gigs, interviews, publicity, CD and t-shirt sales — in short, anything that leads to work, money and/or fans.

Getting such work is just the beginning. Gigs must be confirmed weeks in advance and promoted with flyers, press releases and reminders to my mailing list. Music festivals and competitions have submission deadlines and requirements. Music writers are always on deadline and even weekly calendar listings have a window. With every opportunity there’s a whole slate of peripheral tasks that must be addressed. And somewhere in there I have to rehearse and bang out a new song every so often. When you are a working musician, your to-do list is always full. Always.

Personally, I don’t like automatic syncing between devices — it’s brain-dead. Manually transferring the information at least once allows it to tickle my brain a bit and stimulate new ideas. It’s sync with a built-in review.

After a while I realized I needed some serious-yet-simple organizational fu to keep things moving. I recently became enamored of Jim Munroe’s “Time Management For Anarchists” and his penchant for agenda books, so a few years ago I started the haughtily-named “Book Of The List,” which is a Mead Fat Lil’ Notebook containing a forever-running to-do list. When I have a task or idea, it goes on the list. There’s really nothing special about it, except it’s fun to look back and see that the very unsexy “get more 9×13 padded envelopes” was once very important in the fall of ‘03.

Inevitably, some stuff on the List gets skipped over and buried. I try not to worry about these items and either prune them out or move them to a new position at the top. The only time I get nervous is when the List gets empty — that’s when I know I’m not spending enough time filling the funnel.

For time-bound tasks, I couldn’t live without my Yahoo! Calendar. It’s truly my outboard brain. I’ve tried far sexier apps, but honestly, I don’t need the distraction of a shiny Ajax-enabled funhouse. Y! Calendar is free, offers multiple calendar views and unlimited (AFAIK) email and SMS reminders. The reminders are crucial since I often get drawn into day-job minutiae and forget that Rizzo the Talent Buyer can only be reached at the club between 2 and 3 on Mondays. I usually put contact numbers and brief notes in the subject line and route the reminder to my cell phone so I can take action even when I’m away from a computer.

I review the BOTL and my Y! Calendar several times a week and love transcribing tasks between the two manually. Personally, I don’t like automatic syncing between devices — it’s brain-dead. Manually transferring the information at least once allows it to tickle my brain a bit and stimulate new ideas. It’s sync with a built-in review.

Filling The Funnel

Enough about tools, let’s talk gigs. I’m going to assume you already know how to secure a gig for your act, but there are always ways to grease the wheels. What follows are some general ideas that have helped me keep my gig calendar full.

You should have a good website. I won’t presume to tell you how to build a good website, but I will say this: if you don’t have a few full-length, downloadable MP3s on your site, do it now fer cryin’ out loud. A lot of talent buyers simply don’t have time to listen to CDs, so make it easy on them and yourself. And make them streamable too, since not all venue owners have broadband.

Mercilessly plunder other artists’ websites for information. Find similar artists in your area, steal their calendars and find where they intersect (both MySpace and Garageband are great resources for this). Or, just flat-out ask for referrals. Most artists enjoy info-sharing and the accompanying ego boost. Well, it works on me (I’m writing this, no?).

You’re going to be sending a lot of email to strangers and asking the same questions over and over. A good email program (I use Mozilla Thunderbird) will let you design and save email templates for these tasks. I have standard templates for booking inquiries, press releases, thank-you notes, introductions to other bands and a few others.

I like to put identifying text like “[booking]” or “[calendar]” in the subject line of the email inquiries I send. It signifies the topic, and allows me to filter any responses into corresponding folders. If I’m expecting a response, but don’t get one, I usually follow up with a slightly altered subject line, such as “[booking] 2nd try: openings in January?” to indicate friendly persistence. Don’t forget to schedule your follow-ups immediately — again, this is where a calendar with reminders can be extremely handy.

Google rules. I use Google Maps and Google Local to find alternative venues to enhance existing gigs. If I have a gig in a particular city, I could use Google Maps to search for the nearest Borders and set up an in-store performance during the day. Ditto for indie record shops, college campuses, radio stations, etc.

If you seriously want to increase the number of shows you play per month without exhausting your audience draw (I call this “overfishing”), I highly recommend the “zone strategy” developed by Joe Taylor in his book “More Gigs Now.” It’s a clever way of exploring the geography of your area to find more gig opportunities by subdividing it into “zones.”

Be helpful. Hook others up with gigs and contacts when you can. If you have time, be a street team member for smaller out-of-town acts you’d like to swap gigs with. This stuff will come back to you in a good way. I once landed an awesome gig opening for a nationally touring major-label act, all because I forwarded some useful info to a promoter I met on a plane.

Weeding The Garden

Fans are the lifeblood of any music career, so I regard anything that doesn’t square against either goal with extreme prejudice. This saves me tons of time which I can then devote to more creative stuff.

A gig should serve a purpose, a reason for you to bother with it. As opportunities come your way, you should be gauging each one against your goals. You do have goals, right? Are they written down? Well, how do you know you’re making progress, then?

Goals don’t have to be awe-inspiring like “perform at Red Rocks.” I prefer my goals to be smaller, easily measurable and ongoing. As a performing musician, I have two very straightforward goals:

to win new fans
to keep existing fans interested and happy

Prune out tasks that aren’t relevant to your goals and your musical style. If you’re a jazz ensemble, don’t spend your energy trying to get the local indie-rock rag to write about you. Don’t bring your punk act to a coffeeshop. Don’t post flyers for your true metal band in Barnes & Noble. Think hard about the style of music you play and the type of people who would like that style. Where do they hang out? What do they read? Focus on those people, ignore everything else.

When was the last time you went to see an unknown band because you saw a flyer? I’m guessing not often. Flyers are “due diligence” promotion. Venue owners expect you to provide flyers even though it’s well-known that flyers do little to attract a crowd. Look at your gigs and decide which ones deserve more attention than others. Some may not warrant a full-court press of promotion. I personally like sending color postcards labeled with the date of the show. They look great, and people can shove them into their pockets and take them home. I get mine done at 4over4.com.

I try to divide my week up according to activity types: Mondays are for press and promotion, Tuesdays are for booking, Wednesdays are for networking, etc. This lets me concentrate on related tasks so I don’t have to worry about spreading my efforts. I use a kitchen timer to maintain concentration: fifteen minutes of answering email, then — ding! — time to switch over to booking tasks for the next 30 minutes.

Ignore everybody. Does seeing others succeed inspire you? Or make you miserable? Sometimes it’s a real energy drain to see another artist achieve his or her goals while your own still seem out of reach. If this is you, learn to put blinders on — stop reading the “On The Scene” column of your local A&E weekly, unsubscribe from Pitchfork and focus on what’s working for you.

Learn to say no. Some bands will take any gig. This is a mistake, and I know from first-hand experience that no one will show up to your gig on Easter Sunday in Kent OH, nor will they show up at back-to-back gigs at the same venue unless you are already wildly popular, or very hot.

And so…?

Here’s the takeaway: if you can devote just a few hours a week to the mundane tasks, you’ll probably be doing more for your music career than most musicians out there. You might even discover, as I have, that you enjoy the sense of accomplishment and — gah! — professionalism that comes from mailing out press releases and promoting your gigs effectively. And if you can stay mindful of weeding out the tasks that don’t fit your goals or don’t get the results you want, you’ll have more time to spend on the stuff that does work. You’ll become a better judge of which activities are worth doing, and which are wastes of time or ego-stroking.

Let’s be clear, though: if you’re anything like me, you’ll fall off the wagon a lot and find yourself spending a few days waving your flippers in the air helplessly. The key is to allow yourself to mope for as long as necessary to recover your resolve, then get back on it. Keep at it long enough, and maybe someday you’ll impress and attract people who’ll do this stuff for you.

Oh, and don’t quit. Never quit.

Scott Andrew began his professional music career years ago in Akron OH, playing Police and Pink Floyd covers to drunken college students in a cover band called Cartoon Freeze Tag. He has since relocated to Seattle, where he ekes out a schizoid existence as a web developer and frustrated acoustic pop superstar. His music is available on his website under a Creative Commons license. Scott also has several CDs available, for money.

”Guest post: Scott Andrew on "Productivity for the Practicing Musician"” was written by Merlin Mann for 43Folders.com and was originally posted on November 07, 2005. Except as noted, it's ©2010 Merlin Mann and licensed for reuse under CC BY-NC-ND 3.0. "Why a footer?"

Guest post: More on distractions, from Paul Ford

ford — Mon, 24 Oct 2005 06:58:22 -0400

Last week, I enjoyed and linked to Paul Ford’s Ftrain post, “Followup/Distraction.” It led to us exchanging a few chatty emails, so I asked Paul to favor us with a deeper write-up on his idea of narrow vs. broad distractions. More specifically, I asked: “Is there such a thing as a good distraction?”

Are there "good" distractions?

by Paul Ford

Gary Benchley, Rock Star
by Paul Ford

I don't want to differentiate between "good" distractions and "bad" distractions. I want to stick to the idea of "narrow" and "broad" distractions. Because sometimes a broad distraction--like, say, getting drunk and watching the movie Red Dawn--is exactly what you need. In fact, one of the best things I can do when I'm in a rut is go see some utter-crap movie that features CIA operatives and lots of gunfire. I like to goof off a whole lot. I think it's insanity to try to justify that in any way.

I struggle, though, because my PC can play a DVD of Red Dawn while I check my email and work on an essay. This sort of computing power is fine for strong-willed people, but for the weak-willed like myself it's a hopeless situation. My work requires me to patiently work through things and come up with fresh ideas. And I can honestly say that since broadband Internet came to my home a year and a half ago my stock of new, fresh, fun ideas has grown very thin. It's just too much. My mind can't wander, because, with anything that interests me, I can look it up on Wikipedia to gain some context. Before I know it I've got thirty tabs open at once in Firefox. Then new email comes in. I loathe the way computers blink to demand your attention; the computer wants to tell me, for instance, that it can't load a web page. On the Mac, my Firefox icon starts jumping up and down like an anxious toddler (I know I can probably turn this off, but there are always more pop-up windows). My computer constantly wants to share totally asinine, useless information like that with me. So I've started using an Alphasmart Neo to draft text, and WordPerfect for DOS to edit and revise. My average daily word count has doubled as a result, and my stock of fresh ideas seems to be replenishing.

Talking about Harper's Weekly

One of my tasks at work is to write a weekly roundup of the world's news called "the Harper's Magazine Weekly Review." It's a free weekly compendium of despair and hopelessness. We send it out via email to tens of thousands of people and put it on the web. And I feel a real duty towards those readers to somehow summarize the week, to try to capture the world, and to entertain my audience as I do so. I've been writing it every week since February, 2005, when I took the Weekly over from the person who created it, Roger D. Hodge, after he became Deputy Editor at Harper's Magazine and was too busy to write it every week.

At first I thought that the only way I could write a summary of the week's news was to be truly, broadly distracted. I followed as many links as I could. I set up an RSS reader with literally one thousand feeds--every possible news source I could find. But it didn't work. An RSS reader seems like the perfect application if you're trying to write a summary of the world, but it was worse than useless. I was including too many different events, and my Weekly Reviews were too long and ponderous. Looking back on them I can see myself struggling. So I went to Roger and asked him how he used to put the Weekly together each week without losing his mind.

“I set up an RSS reader with literally one thousand feeds--every possible news source I could find. But it didn't work. An RSS reader seems like the perfect application if you're trying to write a summary of the world, but it was worse than useless.”

Roger is an uncannily organized and diligent person, and I learn a great deal by watching him in action. What he used to do, he told me, is take the New York Times and read it over the week, then circle the stories that were interesting, tear them out, and put them in a pile. Most of the important details, he said--the most revealing quotes from politicians, the most obscure, ridiculous details--tended to be well into the story. He supplemented the things he learned from the Times with his other reading, with Google News searches, and so on. But there was a single source that he used as a starting point. So I canned my RSS reader and started using the Times as my base of operations, and began to read individual news articles with much more care. Immediately my prose was tighter because, by going slower, I became more informed about the subjects I was trying to summarize and was less overwhelmed. The number of subscriptions to the Weekly Review shot up right away and I got a great deal more positive feedback from readers. Readers could sense that I was more confident, I guess. I haven't opened an RSS reader in five months. I just peck away during the week, gathering news stories, a few each day. I use BBC News more than the Times, now, because I prefer to read online and the BBC News site is incredibly easy to navigate and has good coverage of world affairs. On Monday morning I edit and put it all together--I use a spreadsheet with one line per statement and source--and check my facts. Then three people edit it, one after another, which is a real privilege, because they invariably catch me doing something stupid.

On "Amish Computing"

When I tell other geeks about these processes (and God knows talking about process is something that we tend to do the point of exhaustion), I sometimes get accused of being a Luddite, which is nonsense. I love technology with a passion. I spend half of each day programming Java in Eclipse and use Subversion to manage files; I enjoy hacking around inside of Apache and Tomcat. I love Semantic Web technologies. But my personal goals are pretty specific: I want to be a good writer, and I want to have a full command of web technologies. This means that I must spend a lot of time writing and thinking, and working in my little corner of the web. I try to focus on these goals for between eight and twelve hours a day. And during those eight or twelve hours there are narrow distractions that help me become a better thinker--say, an interesting article about a new Java technique or a really interesting, well-edited galley that's going around the office, which I'll read and think about--and then there are disasters, like reading Slashdot threads, or meandering through Google News, or "researching" something on Wikipedia and following a chain of fifty links.

“For most of my life people saw me doing the things I liked to do and said, 'you have too much free time on your hands.' I’ve decided that when you hear that it means you’re doing something right.”

These last few months I've had real trouble getting things done(™), which has really bothered me because I really like programming and writing; those are two of my favorite things to do while sitting. When I'm not getting enough done I get unhappy and depressed and think about the billions of years I'll be dead before the heat death of the universe erases everything. I want to feel like I did something during my brief life besides check my email. And lately I've been working hard to become more productive. I've started quit every application that isn't relevant to the issue at hand and tried my damnedest only to allow the good distractions to come in the door, rather than to let the broad, wide world in at all times. I try not to multitask when I can help it. I think of this as "Amish Computing." You push the worldly things away because they distract you from your goals.

I've been programming and designing a new version of Harper's website, one that can grow over the years to accommodate every page of the magazine since it began publishing in 1850. I think it's a worthy task and I want to do a good job. It's my responsibility to design the site, program the subscriber functions, and going forward, to see hundreds of thousands of page images scanned, corrected, and quality controlled.

The Amish don't drive cars. My "car," with regards to programming the new Harper's Magazine website, would be something like Ruby on Rails. When I see something like Ruby on Rails I get very excited and think, "Wow! I'll be able to learn a whole new set of skills, and I'll spend hours hacking away, creating new problems to solve. Come on AJAX! Come on dynamic database objects!" But I have this big set of problems I'm already trying to solve, and I have the skills to solve them, and a roadmap already written. A few months ago I spent several days dabbling with Ruby on Rails, wondering if I should ditch Java for the Rails framework, until I realized that it was just another broad distraction posing as a narrow distraction. Not to say it's not a great advance, but in my life switching over to Rails would create more problems than it would solve. It would disrupt the close connection I feel with the Java code I've already written. I decided that I would lose more than I'd gain.

Of course, the Amish have a high rate of dwarfism and genetic disease transmission because Amish communities interbreed over generations. This is bad. You need to let the big, broad world in, otherwise we'd all be writing FORTRAN and COBOL. But basically, if you have an Internet connection, you're guaranteed access to the big wide world whenever you want it. The ideas will be there, for the taking, when you need to solve a problem. At a certain level I want to avoid creating new problems just so I can have the pleasure of solving them because then I end up starting projects and never finishing them.

Because I'm a data glutton. When I'm in my most distractible place I don't chew my thoughts properly. The most productive times in my life are the ones where I'm just doing my own thing, focused, and trying to solve some problem that I find interesting--when I'm narrowly distracted. I've met people who are very into model trains, or knitting, or coding games for the Commodore 64, and I feel a real kinship because they find the same pleasure in their activity that I do from writing and programming.

I’m very paranoid about any metric of productivity. One person’s wasted time is another person’s productivity. For most of my life people saw me doing the things I liked to do and said, “you have too much free time on your hands.” I’ve decided that when you hear that, it means you’re doing something right. I hear it a lot less now that I’ve got a novel out and work at Harper’s Magazine, which is a job that carries some prestige. But that doesn’t make sense, because I’m doing the same things I did before anyone else took interest. External metrics are pretty useless. I like to think about Allen Ginsberg, when he confessed to his shrink that all he wanted to was write poetry, and his shrink said “well, why don’t you?” If you measured life by productivity, who would pick up a guitar? Besides, I’m happiest when I’m narrowly distracted—when I’m working on a task and I find it interesting enough that the rest of the world goes pale and I can really focus and explore. And luckily I find “boring” things, like programming and revising text, to be very exciting.

I just want to spend more time doing those things and less time flipping between windows waiting for some new signal to come over the wire. It’s a struggle, because the easiest thing to do is just swim in the ocean of data. I can spend hours browsing the web without coming up for air. But ultimately that leaves me far more bored than doing the mundane, repetitive tasks that constitute “working.”

About the Author

Paul Ford is an Associate Editor at Harper's Magazine, an occasional contributor to NPR's All Things Considered, a contributing writer to TheMorningNews.org, the sole proprietor of Ftrain.com, and the author of Gary Benchley, Rock Star--an amazingly funny novel about indie rock that you will not regret reading (coincidentally, it's available on Amazon.com).

”Guest post: More on distractions, from Paul Ford” was written by Paul Ford for 43Folders.com and was originally posted on October 24, 2005. Except as noted, it's ©2010 Merlin Mann and licensed for reuse under CC BY-NC-ND 3.0. "Why a footer?"

Jeff Covey: Running a _Progressive_ Dash

Merlin — Wed, 28 Sep 2005 06:29:23 -0400

Reader Jeff Covey shares how he’s started beating procrastination with a dash. Jeff’s system features a very fast daily start-up and a clever way to make sure every to-do gets touched first thing every morning.

Running a Progressive Dash

by Jeff Covey

The recent post about running a dash gave me an idea which has turned out to be a good way to get myself in motion. It's something like a train pulling out of a station, with a lot of force and effort at the beginning leading to smooth gliding through the long haul.

One of my gtd scripts is named "tenmins", and I've used it to make sure I put at least a little time into each of my next actions lists each day. As the name implies, I picked ten minutes as the arbitrary amount of time to give each category of work. tenmins would look through my lists for any which had items waiting to be done. Then it would say, for example, "work on phone calls", display a timer counting down the time remaining, and pop up a message saying "stop" when the time was up.

Last week, I decided to try putting tenmins on a loop which starts with one minute for each category and adds another minute on each iteration. I start the day with an all-out sprint through my work landscape with a minute for each actions list, then stretch out with two minutes for each, then three and four and so on. I'm finding a number of benefits hiding in this simple trick:

Since all bases are touched at least once, my whole workload becomes fresh in my mind after just a few minutes (1 minute * the number of active next action lists). There are no worries that there's something waiting in hiding to bite me.
I rush at the beginning of the work day when I'm fresh, and at a more leisurely pace later, instead of spending a lot of time on one thing (not necessarily the most important thing) and facing a panicked race to get through everything else. I have progressively more and more time to get things done, instead of less and less.
As I add items to my lists, they get done more quickly, or at least started sooner (the next time that list comes up in the cycle).
I feel my load lightening as I dispatch everything that can be done in one minute, then two minutes, etc. By the time I get to something that's going to take an hour, I know there's really nothing else I should be doing.
Chipping away at a project one minute at a time, then two, then three, I find projects starting to be finished today that I thought would take the rest of the week.
The reverse psychology described in The Now Habit comes into play. I take something I don't want to do at all and limit myself to only spending a minute or two on it. By the end of that time, I wish I could continue and get more done. Pretty soon, I'm wanting to get back to it and finish it instead of procrastinating about it.
Since I only have a minute to get started on something, sometimes I just use screen to create a new screen, name it after what I'm doing, and open a document or start a program or do whatever it is I need to get started. Then, when it comes around again, the work material is already laid out, and it's much easier to get started and do something even in just two or three minutes. When I have a screen dedicated to a certain project, I'm more likely to want to get that project done and close the screen than to close it undone.

I’ve liked this so well that I’ve added three more notices to the end of the tenmins loop:

Incoming mailboxes: Once I’ve gone through all the next actions lists, tenmins checks for any non-zero-sized mbox files that procmail has placed in ~/mail/incoming/ (general inbox, work mail, mailing lists, etc.), and asks me to spend x minutes on each. If I get done early with one of them, I grab the next one and the next until time’s up. By the time tenmins is through finding ones I haven’t already emptied, I’m often back to zero.
Postponed mail: tenmins then checks whether I have any draft messages in ~/mail/postponed and bugs me to work on them.
Reading: When everything else is done, tenmins asks me to spend some time on my list of things to read (articles, books, RSS feeds, etc.).

I wouldn’t recommend this as a regular means of working; constantly changing from one project to another can break your chain of thought. It can frustrate you when you come back to something and have to spend time getting back into the flow of it, trying to retrace where you were headed before the last interruption. But though it may not be the best way to choose how to use your time all the time, it can be a good trick for getting you moving on all fronts, especially if you’re not sure what to do next.

— Jeff Covey

”Jeff Covey: Running a _Progressive_ Dash” was written by Merlin Mann for 43Folders.com and was originally posted on September 28, 2005. Except as noted, it's ©2010 Merlin Mann and licensed for reuse under CC BY-NC-ND 3.0. "Why a footer?"

The DIY Planner: Hipster PDA Edition

Merlin — Mon, 13 Jun 2005 05:42:00 -0400

a million monkeys typing » D*I*Y Planner Hipster PDA Edition

Geek worlds collide as Douglas Johnston releases the “Hipster PDA” edition of his popular D*I*Y Planner. As with the classic version, Douglas has adapted and refined popular “paper planner” templates—only this time they’re tailored to fit on our beloved index cards.

To commemorate this august occasion, we’ve asked Douglas himself to share his thoughts on why paper seems to be making such a comeback (if it ever “went away”), including some insights into who this format may and may not work best for.

Great work all around, Douglas!

The DIY Planner: Hipster PDA Edition

by Douglas Johnston

In this day and age, paper-based planning (PBP) is a notion roughly analogous to horse-and-buggies, pneumatic networking, sliderules, and steam-powered lawnmowers — in other words, ancient technology.

So, why are we suddenly seeing a resurgence in paper-based organizational tools like planners, index card sets (a.k.a., the Hipster PDA), file folders, pocket briefcases, and honest-to-goodness real-ink pens? Outside of a number of philosophical reasons, I believe that it's ultimately a matter of knowing that these things actually work. After all, not even the trendiest tools last for more than a season if they don't deliver (and I have a junk drawer overflowing with orphaned gadgets to prove it). There's a proven track record behind paper-based planning, and an endless array of options for those people wanting to define --and redefine-- their systems.

Despite being an IT professional, I've found that the dozens of technology-based systems I've used over the years have never really been fully effective solutions for managing my time and projects, and so bits and pieces of my life are now scattered in a hundred incompatible systems, never to be seen again. The last straw was when several of my Palm databases became badly corrupted last year, the bad data having also spread to the desktop and the backups: needless to say, much was lost. I began to wonder if the Day Runner I used a lifetime ago could be resurrected and made useful again. This plan had its problems, however: not only was the nearest Staples a four-hour jaunt away, but their shrink-wrapped forms were quite limited in variety and usage, not to mention very expensive -- a typical pack of 20 To Do sheets was about $5 USD. The D*I*Y Planner project was thus born as a way of providing a wide assortment of forms at little cost. (Although, my wife might argue that I was just being cheap.) With the realization that others might find it useful, I decided to create a system that could be tweaked to suit almost any methodology or situation, relying heavily upon user feedback for ideas and direction.

The latest member of the D*I*Y Planner family is the Hipster PDA Edition, a set of 34 organizational and planning templates designed specifically for 3x5“ index cards. I've received hundreds of requests for a kit like this, many claiming it was an important option for creating an ideal customized system. At first, the demand took me by surprise; after all, why would you want to print so tiny on cards that contain so little information and are so hard to file?

The bits that work well...

The past few weeks, I've been experimenting with the Hipster PDA and the cards that people have asked me to create, and I now admit my initial impressions were born of ignorance. So why do these work?

Portability

Although I've never minded hauling my planner around, sometimes the “weight-to-usefulness” ratio is a little low. It's far more sensible to take a grocery list on a card to the supermarket than your entire project portfolio, for example. A pack with a few GTD All-In-One cards, a few Notes cards, and two months' worth of calendars is a great way to be portable. The most important info for the day can be written on them before you hit the road.

Focus

I have about 200-300 pages in my Day Runner, most of which aren't of immediate importance. In contrast, the Hipster PDA emphasis is upon short-term planning and productivity, which means that you don't have to carry around the next six months of materials, only the basics you need for the day or week; this essentially forces me to focus on getting things done now. This fits quite well with the immediacy of the GTD philosophy.

Scratch

Even if you use a regular paper planner or software like Outlook/Entourage, DEVONthink, Tinderbox or wikis, these cards make great scratch pads for moving information into a more permanent solution later. I've started hauling around a Hipster PDA during the day as I go about my business, and then settling down with my regular “classic” kit in the evenings, transferring and processing the most important details. I then review my projects, calendar, actions and references as normal, and jot info onto the cards for the next day.

Structure

Now, Merlin's initial concept of the Hipster PDA stressed simplicity and portability, which is probably why it caught fire. However, a number of people do like forms that help structure thoughts, and they like the feel of a bona-fide “product” that looks like it was meant to help them organize. I don't see this as hand-holding, but a form of inspiration and motivation. Plus, each field is a potential prompt for you to think about what you're doing, and why. (Of course, in no way does this diminish the free-form thinking you can do on a blank card.)

Technique

Anyone addicted to 43 Folders knows the importance of refining one's techniques for the sake of productivity, and part of the fun is experimenting with new methods and forms. The Hipster PDA in general, and some of these templates in particular, provide the opportunity for tackling your day in completely different ways. For example, I've fallen in love with the “flip-it” version of the monthly calendar: the top three weeks are on one side, the bottom two weeks on the other. Since I only have a couple of items per day (most tasks fall into my Next Actions lists), it's perfect for me. I've also heard back from a few testers who are really enjoying the Covey Roles and Covey Quadrant forms, because they're using them to explore the top-down approach for the first time. I've tried to advocate tweakability with the D*I*Y Planner kits, encompassing as many methodologies as reasonably possible, so there's plenty of room for experimentation. (A blessing or a curse: you decide.)

To keep your mojo rising, I've also included two quick-reference cards: one being a Getting Things Done flow chart, brain tickler, and weekly review list; the other based on Covey's First Things First, a little cheat sheet for weekly planning, daily work, and reviewing.

Cachet

You know those boardroom meetings where some people haul out tattered $2 notepads from the office supply company, and others whip out sporty PocketPCs, wireless Palms, and 12“ ThinkPads and Powerbooks? Think there isn't jealousy in the air? I think a nicely-constructed Hipster PDA has the same sort of caché. People seeing these babies —nicely printed and organized— seem inherently fascinated by them and often ask where they can buy a set. Hauling out a stack of these in front of your boss can only serve to impress. (Yes, we organizational geeks can be slaves to fashion, too.)

..And not so well...

This is not to say that the medium and design don't have their downsides, for some people and certain situations:

Filing isn't quite as easy as with regular paper. The thickness and size of the cards make permanent storage a little problematic. True, you can keep lots of index card storage boxes or bulky envelopes, but this is clunky compared to a typical file cabinet with folders designed for larger, thinner paper. If filing is a necessity for you, then you might think about transferring your information to another medium.
It seems like 30 cards is a ”sweet spot“ in terms of toting the Hipster PDA around and shuffling for data. This is great if you just carry a calendar, some action lists, some notes, a few project sheets, and a bunch of blank cards or forms. If you want more —like numerous reference lists, full project details, a year's worth of monthly calendars (or a month's worth of daily calendars), and so on— then the deck becomes unwieldy and tends to make finding information difficult, even with tabs or dividers (which, again, increase the thickness). If you're an information junkie, you might be better off with a ”classic“ planner or a high-tech PDA.
The small size of the forms necessitates a 0.15 inch line spacing, which also seems to be a standard for small paper planners. This height is fine if you can print small and have a 0.1 to 0.3 pen, but if not, your cards might soon be a mess.
Like any other system, integration is always an issue. Can you make the Hipster PDA work in conjunction with your other organizational tools, or will it be just another alluring productivity distraction?
Paper cuts. Clumsy people should also carry a few band-aids.

This is just a summary of what I personally find to be the upsides and downsides of working with the Hipster PDA version of the D*I*Y Planner; your mileage will vary wildly. Whatever the case, I still believe it's a great option for experimentation, and I'm going to make the Hipster PDA a permanent part of my own kit.

Just a final note: both the regular 'Planner and Hipster PDA kits were influenced by hundreds of requests, questions, comments and complaints from users, readers, and especially the members of the 43 Folders Google Group. My deepest thanks and appreciation goes out to these people: you've helped shape this product, and deserve much of the credit. Hopefully, it reflects far different and wider needs than my own; this, I think, will be the key to any success.

Danny O'Brien: Question on geeks and games

Merlin — Mon, 25 Apr 2005 05:10:00 -0400

As you may know, Danny O’Brien and I are rumored to be working on a book for O’Reilly’s Hacks series. As we theoretically toil with this theoretical book, we’ll be lazily turning to you smart people from time to time to save our bacon. This is the first of those occasions.

Thus, Danny asks…

So one of the things that’s cropping up in the research is that geeks hate boredom more than other people: indeed, more than life itself. The whole “rather gnaw your own arm off??? is frightening close to reality here.

Given the choice between a fractionally tedious task that will save hours of effort, and something capitivating and challenging, we’ll bunk off the former.

I don’t know yet whether that’s not something that’s applicable to other people. But I am interested in linking this up with another bit of anecdata, which is that geeks often enjoy thought games and puzzles.

So, here’s my question: when you have a regular, mind-crushingly dull task to do, do you have a little game you play with yourself to make it easier? If so, what is it?

(Merlin reminds me to include the canonical Simpsons reference in this discussion:)

Principal Skinner: Oh, licking envelopes can be fun! All you have to do is make a game of it.

Bart: What kind of game?

Principal Skinner: Well, for example, you could see how many you could lick in an hour, then try to break that record.

Bart: Sounds like a pretty crappy game to me.

Principal Skinner: Yes, well… Get started.

”Danny O'Brien: Question on geeks and games” was written by Merlin Mann for 43Folders.com and was originally posted on April 25, 2005. Except as noted, it's ©2010 Merlin Mann and licensed for reuse under CC BY-NC-ND 3.0. "Why a footer?"

Guest: Mike Harris looks at "Remind"

Merlin — Thu, 24 Feb 2005 18:34:23 -0500

How much do I love my readers? So much.

Mike Harris very kindly sent me a suggestion about having a look at Remind, a swell little Unix program for doing CLI stuff to give yourself, well, reminders. It’s really quite powerful, that.

Despite my initially flipping the bozo bit by asking for technical support about installing Remind, Mike responded with one of the most useful emails I’ve received in a year. So good, that I asked him to move a couple things around and turn it into a full-length guest feature for 43 Folders. So he did.

Many thanks, Mike. I'm still getting my head around a lot of this, but already see many uses for this. Fellow Unix noobs: this looks like a pretty good first project, eh?

Remind

by Mike Harris

I’ve found a lot of the advice on 43 Folders useful (particularly the Quicksilver append trick and the mere concept of plain text being a lot more simpler of a mechanism to handle ‘to do’ lists), but had continually run into a problem — I hated having to deal with what I felt were bloated, inefficient GUI calendaring programs. I thought to myself, “Surely, with Unix having been around for a few decades by now, someone’s figured out how to have this done in plain text.” Sure enough, I was right.

Roaring Penguin is currently the caretaker of an open source project that has, in one form or another, been around since 1988, called Remind. Remind is a Unix-driven calendaring program of great flexibility and power, but, better yet, for the most part, it works with the command line and with plain text. With the deliciousness of Mac OS X, though, you can integrate it into your background processes and GUI with very little effort and splash.

Installation

In order to install Remind, you’ll need to download the package (available here) and go through the usual three Unix installation commands of ./configure, make, and sudo make install. I know that may feel intimidating to you if you're a Unix newbie, but it's actually a fairly simple process to go through: just type those three commands. Go ahead, try it! (Or, perhaps some guru out there wiser than I could use Iceberg to whip up a nice Mac OS X installer package for it.) [Merlin sez: here’s a bit of help on the holy trinity of Unix installation.]

(Update 2005-02-25 08:09:13: James Rifkin mentions his OS X installer for Remind. I haven’t tried it, but would like to hear how it works for people.)

You’ll also need to create an invisible text file in your Home directory called .reminders that will be used by the program to store all your events and reminders, one per line. To do this from Terminal.app, enter:

touch ~/.reminders

Entering in Your Calendaring Events

The one key to remember is that almost every single entry in .reminders will start with a REM and end with a %. Remind's commands are usually in plain, common-sense English -- REM is to REMind you, MSG is a MeSsaGe, and so on. For example:

REM May 5 2005 MSG Go to the White House, do the hokey-pokey, and turn myself about.%

That statement will show that particular event on May 5, 2005.

Always Useful Tip #1: Warning Yourself in Advance

%b puts either “tomorrow,” “today,” or “in x days’ time” into the text of the reminder. +## starts showing the message ## days before the actual date. In combination, they’re great for giving you countdowns to birthdays, anniversaries, movie premieres, whatever. So, putting this in your file:

REM May 7 2005 +7 MSG My dog's birthday %b.%

Would show “My dog’s birthday in 7 days’ time” on May 1, etc. It’s even smart enough to do “1 day’s time” instead of “1 days’ time”.

Always Useful Tip #2: Recurring Events

There are two very easy ways to handle recurring events. First, leaving out information will cause the task to apply more generally, i.e., leaving out the year will cause it to repeat every year, and leaving out the month will cause it to repeat every month. For example:

REM February 23 MSG This message will show every February 23rd.% REM 23 MSG This message will show the 23rd of every month.% REM Thursday MSG This message will show every Thursday.%

Or, if you need something to repeat every ## days, you can specify that, as well:

REM February 23 2005 *30 MSG Refill prescription from pharmacy.%

That would remind you every 30 days to refill your prescription from the pharmacy, beginning February 23, 2005.

Always Useful Tip #3: Keeping Your Text Files Neat

You can also do ‘includes’ with other text files so that you can keep events segregated, e.g., all your birthdays in one text file, all your anniversaries in another, all your financial deadlines in a third, all your favorite T.V. shows in a fourth. All you do is put:

include [path to subfile]

in the appropriate spot. I find it useful to have a “master” reminder file formatted the way I like it, with my birthdays, anniversaries, financial deadlines, and holidays separated into separate files, and an “active” file that I usually work out of for the more changing events.

Always Useful Tip #4: Just Weekdays, Please

How do you do things like a payday where it’s the 15th and the last day of the month, but not weekends?

REM 1 -1 OMIT Sat Sun MSG Payday.% REM 16 -1 OMIT Sat Sun MSG Payday.%

Semi-Complex Tip: Date-Based Math

You can do date-based math with Remind. Going on a family vacation, and you want to remind yourself every day of how many weeks you’ve got left, and how much money you can save before then? I hadn't originally realized that Remind could do this, but David Skoll at Roaring Penguin helped me work out how Remind could work in weeks, instead of days. From there, it's a quick math problem to apply it to pounds to lose, dollars to save, and so on. These lines, for example, are in my Remind file:

fset _weeks() coerce("STRING", (trigdate()-today())/7) + plural((trigdate()-today())/7, " week") fset _dollars() coerce("STRING", (5*(trigdate()-today())/7)) + plural(5*((trigdate()-today())/7), " more dollar")

Then, you can simply say:

REM August 5 2005 +253 MSG You have [_weeks()] until your summer vacation.% REM August 5 2005 +253 MSG GOAL: Save [_dollars()] for summer vacation.%

Schweet, huh?

Edit 2005-03-03 21:49:32: Keep in mind, however, that Remind can only handle whole numbers in such math equations. No decimals.

Actually Viewing Your Calendar

OK … now that I’ve actually entered in all this crap, what the heck do I do now?

It begins very simply. Once you've entered in your calendaring information, all you need to do is type rem in the Terminal in order to generate today's calendar output. That's it.

Looking at Other Days

You can generate your 'datebook' for other days by simply typing rem [date] at the command line. Remind can use the same variables you see above to let you do aliases for ‘yesterday’ and ‘tomorrow’:

remind ~/.reminders `(echo 'banner %'; echo 'msg [trigger(today()+1)]') | remind -`

will give you tomorrow’s calendar.

remind ~/.reminders `(echo 'banner %'; echo 'msg [trigger(today()-1)]') | remind -`

will give you yesterday’s calendar.

Making It Work with the Mac

How do you get this to interact with the GUI, if you don’t live your life in the Terminal?

You can use GeekTool, which lets you display the output from Unix (and other items as well) on the Desktop. I use it to show a battery script, my IP information, and my Remind output on the desktop, updating every 5 minutes, as you can see in the screenshot above.

You can also install TCL/TK for Mac OS X, and then use the tkremind program that offers a GUI interface to the application. Either tkremind or TCL/TK for Mac OS X seems to be buggy, though, so it’s best to do it through a text interface, in my opinion. (I have been hoping for a while that someone will fall in love with Remind who could write a Mac OS X GUI interface for it that parallels tkremind -- since tkremind can be very useful for working out more established permutations, and is otherwise a very nice wrapper. Any takers?)

The reason I turned to Remind is that it is entirely a keyboard-driven process with no GUI. Because of that, it is incredibly quick, and the Quicksilver append trick I spoke of above allows you to “append” events to your .reminders file. I found this process much more efficient, as I did not have to wait for a GUI program to load, maneuver to the appropriate day, and then work through the application’s “add event” interface. This was also what drove me away from GUI-based "to do" programs and attracted me towards the more simple and portable to-dos-in-a-text-file concept. This makes it extremely easy to add events to a calendar by simply appending text to your .reminders file.

Other Views

Remind features command-line switches that will let you look at your reminders in different ways. You can use -c to generate your calendar for the month in raw text (or -c2 for the next two months, etc.). A slight tweak to that, -c+, will just generate it for the week. You can simply generate a raw list of events for the month using the -s switch instead (the + has the same effect here, limiting it to a week).

When you start generating calendars, you may notice a problem. When creating your calendars file, you may find that you want to subdivide it into categories, like the screenshot. You can do that by just using MSG, without a REM statement, like:

MSG Birthdays:

But, the problem with this is that “Birthdays:” will also show up on the calendar. How do you avoid this? You can append %"%"%. Thus, a subject header like:

MSG Birthdays:%"%"%

would show up on your daily display, but not your calendar. Likewise, you can generate a blank line by:

MSG %"%"%

Note that there are two spaces between the MSG and the %"%"%. For some reason, it won’t work well otherwise.

Aside from generating the calendar in text, you can also generate it using HTML or Postscript. You do so by “piping” the output through one of two programs that come with Remind, rem2html and rem2ps. It’s probably easier to let the manual guide you through that one, or, if there’s enough of a demand, I can maybe cover it in a second article. The process is a little complex if you are new to Unix or the Terminal.

Conclusion

This sounds incredibly complex, doesn’t it? In actuality, it’s really very simple. I love the fact that I can jump into a text file and type out a quick line (or, once I work out exactly how I want to do it, through Quicksilver’s append function) without having to wait for iCal or Entourage’s interface to load, which, on my iBook G3, is slower and often lets me lose the thought before I get it open. Remind lets me do it easily, quickly, and unobtrusively.

If you’re a power user that already is champing at the bit to go further, keep in mind that Remind has a lot more power under the hood than described here. Even I’m a Remind newbie. Remind can handle timed notifications, its output can be piped through Growl, and so on. This article barely scratches the surface of what Remind can do — this baby has a lot more horsepower under the hood.

If you want to learn more about Remind than spoken here, the first thing to do is to read its man page (installed on your system when you installed Remind) from start to finish. After that, three places to get a little more information are Linux Journal’s article “Remind: The Ultimate Personal Calendar,” MacDevCenter’s “Unix Gems for Mac OS X,” and the Remind-Fans mailing list. Check them out!

— Mike Harris

P.S. By the way, while I’ve got the mike, let me say that as a keyboard-oriented person, I’ve learned to love Butler creator Peter Mauer’s Witch, a window-specific application switcher, and Mailsmith, which is a fantastically powerful e-mail program with strong filtering and script support.

P.P.S. Leave me a comment here if you run into problems! I can’t promise immediate or knowledgeable responses, but I can promise to help.

Thanks a million, Mike. That was great! Grab a 12-pack and a Hipster PDA out of petty cash.

Got a good recipe for Remind that you want to share? Post to comments or trackback.

”Guest: Mike Harris looks at "Remind"” was written by Merlin Mann for 43Folders.com and was originally posted on February 24, 2005. Except as noted, it's ©2010 Merlin Mann and licensed for reuse under CC BY-NC-ND 3.0. "Why a footer?"

Guests

Michael Buffington: iGTD + Quicksilver + subversion

Create some Ruby!

!/opt/local/bin/ruby

About the Author

DavidCo's Robert Peake on "Getting Software Done" (part 2)

Part II: GTD and Extreme Programming

Guest Post: DavidCo's Robert Peake on "Getting Software Done" (part 1)

Getting Software Done

Part I: Why GTD Matters To Programmers

Guest Review: Fraser Speirs on "Time Management for System Administrators"

Book Structure

The Cycle System

Create Your Schedule

Create your To-Do List

Prioritise and reschedule

Do The Work

Finish The Day

Other Parts

Automation

Summary

About the Author

Guest post: Scott Andrew on "Productivity for the Practicing Musician"

Productivity for the Practicing Musician

Tools

Filling The Funnel

Weeding The Garden

And so…?

Guest post: More on distractions, from Paul Ford

Are there "good" distractions?

Talking about Harper's Weekly

On "Amish Computing"

About the Author

Jeff Covey: Running a _Progressive_ Dash

Running a Progressive Dash

The D*I*Y Planner: Hipster PDA Edition

The D*I*Y Planner: Hipster PDA Edition

The bits that work well...

Portability

Focus

Scratch

Structure

Technique

Cachet

..And not so well...

Related Links

Danny O'Brien: Question on geeks and games

Guest: Mike Harris looks at "Remind"

Remind

Installation

Entering in Your Calendaring Events

Always Useful Tip #1: Warning Yourself in Advance

Always Useful Tip #2: Recurring Events

Always Useful Tip #3: Keeping Your Text Files Neat

Always Useful Tip #4: Just Weekdays, Please

Semi-Complex Tip: Date-Based Math

Actually Viewing Your Calendar

Looking at Other Days

Making It Work with the Mac

Other Views

Conclusion

The DIY Planner: Hipster PDA Edition

The DIY Planner: Hipster PDA Edition