Rock genre terminology considered asinine

Recent craigslist internet engineering jobs, exclamation point:

** Rock Star (Affordable) Flash Developer Needed ASAP!

** Seeking a rock star DBA for our production environment!

** Great Opportunity for a Rock Star Intern!

Before interviewing for these positions, be sure to comb your mullet and put a cucumber down the front of your spandex pantsuit.

On any given day, about 30 craigslist job postings in my area are looking for "Rock Stars". They are all really looking for "programmers", so, as I am about to enter the job market, I happen across them with increasing frequency.

I have to ask myself: How the heck did "Rock Star" eclipse "productive"?...and why haven't other industries caught on? Where did this trend come from?

No, Captain Klaa(pictured) has not been going around writing corporate dress codes, and yes, perhaps these HR departments are a bit too exuberant(see below). But that's not why I'm looking into this.

I don't have a problem with the use of the term "Rock Star" per se. I don't want to make fun of anyone. I enjoyed Spinal Tap as much as the next guy.

No, I'm looking into this because the trend really got on my nerves. I couldn't put my finger on why that was; so I explored it, and learned something.

I think these employers are trying to do two things:

1) Find programmers that are very productive (top 1% preferrably).
2) Imply that they will treat them well.

What I think they really want is to:

1) Attract programmers who know they are very productive and easy to work with.
2) Imply that they their team is productive and easy to work with.

If you have recently read Joel Spolsky, you may feel the need to replace "productive" with "gets things done" - I won't feel bad.

Thinking about how these employers can get what they want, I found what I really want: a productive, easy-going team. The heart of my problem with a team of Rock Star's is that it's so far from that ideal.

I asked roughly the same questions that employers ask. It was so informative to me that I would recommend it to anyone looking for a job. Here's what I came up with:

1) How do I know I am productive?:

Well, I can measure it.

The employers who are looking for rock stars have probably read that timely tome - The Mythical Man Month, in which the productivity of programmers is said to vary by an order of magnitude by skill alone. Well, this is one of the things that is still true in that book, but not in the way most people probably think.

Most people know how to measure their own productivity. They can describe what they have produced, and discuss it at length. "I developed X in Y weeks and I here it is", etc.

To most employers, your past productivity in the domain of the job in question is the primary measure of your likely future productivity.

Most people are o.k. with that. It's just common sense that you improve at a task with experience. This is hard to measure, but anyone who plays chess might assume that from competent to expert there may be 100 or 1000X improvement in most fields to be gained by experience. As it turns out, this is a highly contentious assertion. No one knows how much experience really has to do with it.

In absence of a candidate that is productive in the required domain and easy to work with, an argument can be made that a candidate that is trainable and easy to work with will do.

Trainable is usually a secondary requirement, and you can measure it the same way you measure productivity, based on past performance. In the case of a programmer out of school, trainable may be the only applicable requirement.

The more experience and intelligence the better. That's nice, but...

2) How do I become more productive?

Most people have a decent understanding of the factors upon which their productivity depends. It may vary from person to person and purpose to purpose. For me, right now, it consists of four things that I seek to improve upon daily.

Domain experience:

Produce more. Focus on one job for a while, and you will become an expert. I may be an order of magnitude more productive at writing support scripts or IVR applications than I am at writing web applications. At some point in the near future, however, I expect this situation to reverse. This just makes sense. I am working on web apps every day. If I want to get good understanding the core concepts of a framework and writing large programs in that framework, then there is no substitute for doing that.

Tool expertise:

Programming tools are made from software and improve productivity. New and better tools come out every day. If I spend time every day learning tools, I will improve my productivity. Commit to this, and you will improve.

Mental and physical health:

Stay healthy. My levels of pain, discipline, and energy vary based on my lifestyle. I get up every morning and excercise, clean up, hug my wife, drink coffee, and solve a puzzle. If I don't get a healthy start to the day, or if I don't take care of myself in other ways, I am sure my productivity will suffer.

Environment:

As a programmer, I work best either in a quiet office or pairing with one or more team members at about the same skill level. I can rank environments for productivity as well. The library is fine, a coffee shop is not so good, and home is right out - too many non-work distractions. Nothing compares to a serious, conflict-free, office work environment.

All I can do here is be aware of the quality of my environment, which varies from job to job. Experimenting with environmental improvements can help, as do these helpful techniques for tough environmental situations.

Kaizen.

3) How do we know when someone is easy to work with?

Probably the most important and tricky part of the hiring process, for both the employer and the candidate, is measuring soft skills.

If a candidates tech skills are not up to par, you have to train them. Fine.

Employees with very poor soft skills can destroy an entire company. Experienced employers and employees know this. So what we are looking out for here, are the bottom few percent of the employee pool in soft skills. No one wants a report or a manager like that.

My soft skills can be measured, and so can those of any company. We just ask each other how we handle situations that matter, and check references.

For my part, I have to ask myself tough questions: How many co-workers have I helped, how many have I hindered, what tough problems have I solved with them, what have I learned, and how can I improve?

So how can I improve? Aside from discussing this with past co-workers, knowledge will help: PeopleWare.

It can't hurt to improve, but I think most people are probably o.k. on soft skills. Still, the better adjusted the team, the better for everyone.

And now, a word to folks advertising for Rock Stars:

I don't expect hiring managers to read this, but...

If you would like to project an image of your programming team, a gathering of Rock Stars is probably not what you want. Rock Stars are people who produce hit songs and are worshipped only as long as they keep pumping them out. A collection of rock stars are not likely to work together long.

Sounds like solo-superman programming while surrounded by dysfunctional sycophants and confrontational peers. Probably not what you meant. If that is really what you meant, then I suggest a different perspective.

I could suggest a different analogy...A construction crew is a closer match than a Rock band. It could be that your construction crew wants to design and build the next Guggenheim and drink beers after work, but it's a construction crew all the same.

Better yet, drop the analogies. Mention your team, your management style, your process and your product. Mention that you would like applicants to discuss what they have actually produced, providing examples where possible. Maybe lead with something like: "Highly productive team seeks C programmer" - or whatever actually describes your team and what you are looking for.

Mention that soft skills are important up front. This is a very good sign.

And...Rock on.

Swig-C-Ruby-Pointers Hello World

I'm trying to write C libraries to do some things on the Mac that are not easy to do with Ruby. I found that I had to read several documents and experiment around a bit with SWIG to call a C library function that took a pointer as an argument. This is just one of those things that should not take that much time to figure out.

C library functions that take pointers as arguments and return ints (that covers most of the c library functions I have written) ultimately return an array to Ruby. Uncovering that little factoid, and the swig interface format required to make that process work, was the tough bit.

So, I'm taking a few more minutes to make sure you don't have to do that (and to make sure I don't have to do that long after I forget about this exercise).

Step Zero: get swig.

I install all open source software on the mac with fink. Fink Swig

Step One: Copy my example code - inline below.

I provide what you need to make a ruby callable module called Example that contains the C function SimpleFunc() that you will call with a little ruby test program called testsum.rb.

user-64-9-234-209:~/src/c/simplelib richbodo$ ls -l
total 48
-rw-r--r-- 1 richbodo richbodo 61 Oct 12 16:24 example.i
-rw-r--r-- 1 richbodo richbodo 42 Oct 12 15:52 extconf.rb
-rwxr-xr-x 1 richbodo richbodo 90 Oct 12 16:41 get_it_done.sh
-rw-r--r-- 1 richbodo richbodo 46 Oct 12 16:36 sum.c
-rw-r--r-- 1 richbodo richbodo 24 Oct 12 15:46 sum.h
-rw-r--r-- 1 richbodo richbodo 67 Oct 12 15:57 testsum.rb

Three of these files you already understand:

sum.c - your library

int SimpleFunc(float *modify_me)
{
*modify_me = 5;
return 1;
}

sum.h - your library header - not used by swig unless you tell it to - don't need it here.

testsum.rb - ruby program that calls your library

require 'example'
afloat = 2
# The first return value gets set as expected in first_returnval.
# However, SWIG puts the float in a second return value.
first_returnval,second_returnval = Example.SimpleFunc(afloat)
puts "Your float is #{first_returnval}, and the return value is: #{second_returnval}"

The other three files are specific to getting your swig library going:

• example.i - a definition of your library for swig in swigs definition language. INOUT is a SWIG typemap, so typemaps.i is required.
  

%module example
%include "typemaps.i"
%apply float *INOUT { float *modify_me };
int SimpleFunc(float *modify_me);

• extconf.rb - a ruby program that creates a makefile for your library

require 'mkmf'
create_makefile('example')

• get_it_done.sh - the commands that you run to generate a ruby module from your c library using swig

#!/bin/bash
rm *.o
rm *.bundle
rm wrap_example.c
rm Makefile
swig -ruby example.i
ruby extconf.rb
make
sudo make install
ruby testsum.rb

Step 2: Run the get_it_done.sh script to build and test your module. (it will ask for your password to install the library)

user-64-9-234-209:~/src/c/idlerlib richbodo$ ./get_it_done.sh
rm: wrap_example.c: No such file or directory
creating Makefile
gcc -fno-common -g -O2 -fno-common -pipe -fno-common -I. -I/sw/lib/ruby/1.8/i686-darwin -I/sw/lib/ruby/1.8/i686-darwin -I. -I/sw/include -c example_wrap.c
gcc -fno-common -g -O2 -fno-common -pipe -fno-common -I. -I/sw/lib/ruby/1.8/i686-darwin -I/sw/lib/ruby/1.8/i686-darwin -I. -I/sw/include -c sum.c
cc -dynamic -bundle -L"/sw/lib" -o example.bundle example_wrap.o sum.o -lruby -ldl -lobjc
install -c -p -m 0755 example.bundle /sw/lib/ruby/site_ruby/1.8/i686-darwin
Your float is 5.0, and the return value is: 1

Step 3: Look at the five new files you just created, and understand what they do:

user-64-9-234-209:~/src/c/simplelib richbodo$ ls -l
total 152
-rw-r--r-- 1 richbodo richbodo 3009 Oct 12 16:42 Makefile
-rwxr-xr-x 1 richbodo richbodo 16316 Oct 12 16:42 example.bundle
-rw-r--r-- 1 richbodo richbodo 61 Oct 12 16:24 example.i
-rw-r--r-- 1 richbodo richbodo 17695 Oct 12 16:42 example_wrap.c
-rw-r--r-- 1 richbodo richbodo 5744 Oct 12 16:42 example_wrap.o
-rw-r--r-- 1 richbodo richbodo 42 Oct 12 15:52 extconf.rb
-rwxr-xr-x 1 richbodo richbodo 90 Oct 12 16:41 get_it_done.sh
-rw-r--r-- 1 richbodo richbodo 46 Oct 12 16:36 sum.c
-rw-r--r-- 1 richbodo richbodo 24 Oct 12 15:46 sum.h
-rw-r--r-- 1 richbodo richbodo 644 Oct 12 16:42 sum.o
-rw-r--r-- 1 richbodo richbodo 67 Oct 12 15:57 testsum.rb

• example_wrap.c - created by the swig command, this a c wrapper for your library with a bunch of additional wrapper functions that translate your functions and data into ruby callable functions and data. see chap 21 in the pickaxe.
• Makefile - this is the makefile that was generated by extconf.rb. It will compile your library and that wrapper and make the mac bundle for you.
• sum.o - the object file generated from sum.c
• example_wrap.o - the compiled version of example_wrap.c
• example.bundle - mac osx stores code in bundles, so make makes one and puts it in your site-ruby directory when you type "make install"
  

So that' it. You make that swig interface file, you call swig. Example_wrap.c gets created. You make the extconf.rb file and run it. A makefile gets created for you. You make your project by calling make and you are done.

References:

• Chapter 21 in the pickaxe book.
• The ruby swig page: http://www.swig.org/Doc1.3/Ruby.html#Ruby_nn5
• The swig basics page: http://www.swig.org/Doc1.3/SWIG.html#SWIG_nn3
• Apple Developer Docs: http://developer.apple.com/documentation/
  

Method for organizing volunteer efforts

The Cancer Beatdown

At it's simplest, it's just a task manager for researchers who would like to utilize volunteers in the search for a cure. For volunteers, it's a way to get their hands bloody at cancers expense. "No, you won't cure cancer, but maybe once in a while, you can come on over here and get a few good licks in". And, yes, I'm going to continue to refer to fighting cancer in more colorful ways than just "fighting cancer". It's quite satisfying.

No money, no donations of protons or neutrons. Just electrons, photons, and elbow grease. This isn't a site for beggin; it's just a site that invites others to get in on the beatdown while the beatin' is good.

The idea is based on the premise that the pool of smart, motivated volunteers is underused and underorganized by the cancer research community. In other words:

1) there are a lot of very smart people who would get a profound satisfaction from knowing that they contributed in some small way to developing a cure for cancer.

2) there are a lot of researchers who will buy that exposing some of their tasks in a sensical way to an army of smart people who want to work on them could speed their work.

One case in which this might work is:

A researcher needed to develop a significant new body of software, and was looking to task some portions of that development out to volunteers in a test-driven manner - "I write the tests, you guys make as many as you can pass before I do".

I recently participated in agile development of this sort, using pivotals excellent agile project manager, which is influencing my thinking on this type of application.

The basic site workflow for Cancer Beatdown is as expected:

1) Site manager invites a few researchers who are doing promising work.

2) Researchers post the task, whether it's stuffing envelopes on-site or coming up with a new way to search a massive database for correlations. The required form of the solution is also specified.

3) Volunteers propose solutions.

Some sensical reputation/core user policies would be adopted - i.e. Researchers or the site manager can invite more researchers, after vouching for them. Volunteers are invested in performance.

Personally, I would love to volunteer for some well-defined and promising projects in which I could invest one day per month. I know some people who would never consider such a thing, and some that would invest considerably more time. What do you think?

Selling on Ebay

Just found this old draft of ebay instructions. If you are going to start selling stuff on ebay, copy these conditions of auction and live by them, it will save you a lot of time and money. The one adjustment you will have to make regards buyer feedback. I stopped selling on ebay when they stopped allowing negative buyer feedback. You can just pull or rewrite those three lines:

Conditions of Auction:

You must agree with our Conditions of Auction prior to bidding. Please do not bid if you do not agree to these conditions.

Shipping Policy:

You will pay shipping as described in the auction.

To avoid damaged goods and provide timely shipment, we will ship as follows:

We only ship air, on-line trackable, on-line signature-required, and fully insured. Internationally, we only ship USPS Express Mail Service.

We do not ship ground by any carrier.

To ship, we require your name, confirmed address, and valid phone number.

We reserve the right to cancel the transaction if we cannot reach you by phone.

Payment Policy:

To avoid fraud, we will ship as follows:

We require payment prior to shipping. We ship within seven days of receipt of payment, usually much faster.

We do not accept payments by check, moneygram, western union, or partial payments of any kind.

Return Policy:

You can return the product within 30 days of receipt if not satisfied for any reason subject to the terms and conditions below.

*** You agree to:

Fully insure any returned item, to the full value of the auction, and to ship via an on-line, trackable, air service.

Provide on-line tracking information on date of shipment.

You will be fully refunded within two days of receipt of goods that are in the same condition they were in when shipped to you.

You agree that we may deduct any costs associated with damaged or missing goods returned from your refund.

Right to refuse sale:

To avoid scams, we reserve the right to refuse sale to buyers with:

* No Feedback
* Poor Feedback
* Private Feedback
* Unconfirmed Shipping Addresses or incomplete contact details.

Service Policy:

No service is provided. No service guarantees are provided.

We will, on a best-effort basis, answer questions via email anytime, or via phone by appointment.

We don't mind answering any questions at all, and we typically get back to you same-day.

Again, those are the conditions of sale. You must agree with those conditions prior to bidding. If you take exception with any of those, please do not bid, or contact us before you bid so that we can work it out. Thank you!

Telepathy UIs

Here is a rundown of "brainwave" game controllers. (bonus idea included)

I first heard about an implementation of one of these in the early 90s by a company called "the other 90%" run by former Atari founder Ron Gordon. AFAICT, very few were sold. Anyway, I still believe it worked. So I had a discussion with someone about this last night. He didn't believe it. Here is some history on the topic:

1974 - EEG control (Sobell - VA Neuropsychology Lab) - Still looking for the actual research study.

1996 - CNN reporting on The other 90% (Atari's Ron Gordon) MindDrive application:

2004 - BBC reporting on MIT implementation

2006 - MSNBC interviews Don Clark of Wall Street Journal reporting on Emotiv game controller.

The reason this works is twofold. First, the composite electrical activity of your brain can be measured and decomposed by frequency and a half dozen clean signals can be discerned. I would call these brainwaves but, according to wikipedia, that is frowned upon for some reason. Second, these patterns change according to thought activity, which is under our control.

Anyway, if one reads about non-invasive brain computer interfaces, it becomes apparent that there is plenty of research in the area. There are also several successful and useful implementations. Not all of them EEG based.

Bonus Idea:

Wouldn't it be cool if:

My jabra bluetooth headset could also send composite brainwave activity to my wildly powerful cell phone, or maybe even my uber-powerful computing cluster at Name_Your_Favorite_Company? In that case, I could generate messages by thinking, while the headset reported the current character.

I have heard somewhere that these game controllers allow you to manipulate 6 tokens based on training them to understand when you think in certain ways.

The first idea that comes to mind is the concept of scrolling through groups of tokens. Lets try sending telepathic messages to each other with just the thoughts Up/Down. (After taking a look at some EEG decompositions, two tokens is, for some reason, quite believable to me.)

Me: Think Up
Headset Audio: "A through E"
Me: Think Up
Headset Audio: "F through L"
Me: Think Down
Headset Audio: "F through L it is - F"
Me: Think Up
Headset Audio: "G"
Me: Think Up
Headset Audio: "H"
Me: Think Down
Headset Audio: "H is the first letter."
...

You get the idea. So you form some text, which gets sent to whoever you are configured to send this stuff to. This gets converted to speech and played back in their headset. They, in turn, send you text with their bluetooth audio/telepathy headset.

Not at all the best UI, but if you can really train yourself to manipulate six binary tokens, the sky is the limit. Can't you just see schoolteachers spectrum-jamming bluetooth signals?

I would appreciate a study that shows a Non-Invasive BCI that was reliably trained to a larger number of tokens. Until then I'll limit my imaginings to two.

Even with two, it is easy to see that the combination of mic/earpiece/brainwaves is powerful. Imagine setting the context with voice: i.e. saying "computer doors" or "computer radio volume", then just thinking up or down to lock or unlock the doors, or control radio volume.

I hope that no one patents this crap and charges exhorbitant amounts of money for this type of tech.

Update: I have to add this link to a cool open-source EEG hardware project: http://pceeg.wikia.com/wiki/Main_Page

You would be surprised what you can find in Open Hardware these days. I will post specs of all the components of the device I describe if I have time. There should be prior are for every component.

Getting Things Done - David Allen - Reviewed by a busy person

I have recently been reading a number of personal productivity and project management books (in typical ADD parallel fashion). If you are a very busy person, you might scroll to the commentary at the bottom of this article, as I am a busy person as well, and I have a few points to make to you.

Summary: Getting Things Done. David Allen. Good productivity tricks. Buy it.

Definitions:

GTD - Getting Things Done - Method for identifying and managing actionable stuff.

Stuff - anything you have allowed into your psychological or physical world that doesn't belong where it is, but for which you haven't determined the desired outcome and the next action step. Stuff clouds your mind until you identify and track it.

Workflow - everything in the book revolves around this list.

1) collect things that command our attention
2) process what they mean and what to do about them
3) organize the results, which we
4) review as options for what we choose to
5) do

Incompletes - categorized stuff not done

Collecting - You are always collecting (work flow 1) stuff by identifying and tracking it.

Collection devices - capture stuff - notepad, pda, email inbox, physical inbox., etc.

Processing triage (workflow 2, 3, and 4) -

1) If it's not actionable, trash it.
2) If it's actionable and will take less than two minutes, do it.
3) If it's actionable and will take more than two minutes, delegate or defer to calendar or "next actions"

Projects - special case incompletes - they are a list of actions that needs to be made and triaged separately.

Next Actions / Next Action - prioritized list of things that need to be done and cannot be put on the calendar because they don't have an associated time that is not "ASAP", next action is at the top. You MAY divide your Next Actions list by category - phone calls, support requests, etc.

Waiting Actions - actions that are blocked on other people.

Lists required for David Allens Method -

* Projects
* Next Actions
* Calendar
* Waiting For

Daily Review - Calendar and Processing Triage

Weekly Review - Everything : gather, process, update all lists.

Decision making criteria:

1) context - where, how can this be done
2) time available - when is there time for this
3) energy available - how much of your available energy would this take
4) priority - which action that can be done has the highest payoff

Purging and getting started:

1) Block out a day or two
2) Buy the office gear he recommends
3) Collect every piece of stuff of every kind and put it in a single inbox
4) Process stuff as usual

Also in this book:

Project planning - not particularly interesting if you are comfortable with your project management skills.

Decision making - very reasonable but not inspiring or particularly specialized section.

Part 2 is implementation ideas for this system - probably a must-read if you decide you want to integrate part of this system into yours - these are all productivity "tricks", similar to those you would find in any personal productivity book, although there are a few unique ones. I will definitely come back to this section in my "organization time".

Part 3 is an analysis of the value of the system. I skipped it at first, but came back to it this morning, and he's got some good points. Worth reading.

Links:

This book is a huge geek-cult hit, so google might be your best bet, but here is what I found useful:

Wikipedia summary of GTD

GTD Tiddly Wiki - a very cool javascript-only wiki that supposedly lends itself to these lists. - in any case, any wiki will do as a list manager, but TiddlyWiki is a single javascript / html file with everything in it, so it's great for offline use. Sync is always a problem, even with this method. You won't always use the same PC. Once solution is to put your tiddly wiki on a thumb drive, in the hopes that you will always be able to plug it in. I tried it and liked it, but will abandon it due to sync/speed concerns and merge back into an svn managed wiki.

Location of a blank GTD TiddlyWiki

Implementation Details:

I did make several purchases based on David Allens advice. I also got buy-in to spend a couple days doing a purge from a few other folk before starting - an excellent recommendation as it turns out.

During my purge I found that the layout of my desk and filing system needed to be optimized right up front for this activity specifically. One thing that doesn't get emphasised in the book is setting up your filing system completely before starting your purge. It's important. You should do that, and set your inbox and trash can right next to the filing system, then begin by bringing your paperwork in. You will need a lot of space. You will probably have to purge your entire filing system if you are really following the book closely.

Oh, and if you are a normal person, you will have to do your purge over the course of many days. The better part of two days got me most of the way there, but I had a lot of work to do over the next couple weeks. Expect 10-20 hours work at least, not including purchasing gear he suggests, if you choose to do that.

Commentary:

Continuous Work Flow Management:

There are some adjustments that I would make to his program for very busy people. Weekly or daily triage is not an option for busy people. For busy people, it is constant, just like the collecting phase, and it has to be treated as a constant if you want to stay on top of it.

As a support manager, when I get in in the morning I might have dozens of new tickets (hundreds already triaged), plus ringing phones, a full calendar, and it just keeps coming. It's like managing a busy restaurant kitchen. I only have the luxuries assumed in this book late at night, on weekends and holidays.

After 12 busy hours at work, the last thing you want are huge lists to triage. So you have to work it constantly - collecting, consolidating and triaging. Yes, you still have to make concerted efforts to triage as completely as possible during the slow times, but infrequent triage won't keep you sane. The drive to organize is more powerful and more urgent for busy people.

There are limits to continuous work flow management. It is easier to rework constantly if you have a reasonable percentage of simple tasks, because you can multitask simple jobs. (i.e. phone call plus monitor a few things plus work down a list of support tickets is do-able, while coding plus work down a list of tickets is nigh impossible). Continuous management is sub-optimal in terms of peace of mind. At some point you have to accept that you are resource starved, and can't fix the problem by shoving management into the gaps.

The Drive to Organize:

There is one profound insight here. The drive to obtain the peace of mind that only a complete and properly prioritized task list can provide is irresistible. He covers this right up front and it's so damn true. Without this peace of mind, life sucks and productivity suffers.

I would add that denial of responsibility is an insidious temptation.

There is a relationship between The Drive To Organize and Neuroticism. I could write an entire paper on Neurotic Time Management. Man, I have been there. If you can do something, it's a good thing to do, and you know you are competent and maybe even the best person to do it...AND you are Neurotic, then you will accept responsibility for it. If you are Neurotic enough, your task list is effectively infinite.

The discipline to "just say no" is covered in a section called "How do you prevent broken agreements with yourself", which for my money is the best section in the book. There is probably nothing there you don't intuitively know, but surely some things you need reminders of: Either don't accept the task, renegotiate the agreement to do it, or do it. Not rocket science, but words to live by.

The Problem with Meetings:

"I envision a world in which no meeting or discussion will end, and no interaction cease, without a clear determination of whether or not some action is needed- and if it is, what it will be, or at least who has responsibility for it." - David Allen (Part 3 of Getting Things Done)

How many business meetings end without the coordinator requesting: "List your action items." I hope that I never run another meeting without making that statement, and never leave a meeting where that request is not made without asking why.

Glad I came back to section 3.

What other busy people think:

I bought two copies of this book which I have loaned to two other busy, organized people. They both said the same thing - yeah, he's got some good tricks. Neither could adopt his system to do their day to day work any more than a kitchen manager at a busy restaurant could, but they both got a good trick or two out of it.