Some day when all the DVDs have decayed and alien archaeologists only have
YouTube to work with, this is what they'll know of the Princess Bride:
Well, unless they happen to find the 10-part series that includes the entire
I might actually run inside in the winter if I knew I was collecting data that I could turn into pretty graphs. Plus, I could put it in my annual report :)
time (minutes),distance (feet),heart rate (bpm)
My three year old daughter Aravis and I were sitting on the couch together. I asked her if she thought she would ever get "holes in her ears" (as she calls it) so that she could wear earrings. She responded, "When I get taller, I'll have brown hair and get married in the temple and get holes in my ears so I can wear pink earrings." That sounds like a well considered life plan.
Everybody should have some reserve savings for the metaphorical
rainy day. How are the family and I doing on this worthwhile goal? As
I mentioned in my post about a life events timeline this data would be
interesting to see next to a list of significant life events to help pinpoint
cause-effect relationships. After doing annual reports for a few years, one
should be able to spot seasonal trends and better plan for them.
What I want is a graph of reserve savings showing the balance throughout the
year normalized against the balance at the start of the year. This won't
reveal to all the world exactly how much savings we have, but will show
how we did at building on (or burning up) the reserve.
The data is easy enough to get. E*Trade stores a list of all the
transactions for our money market fund and displays them in a table like a
checkbook register. Unfortunately, they only export the data in Quicken and Microsoft Money formats, neither of which include the balance data.
With a bit of Perl and some pedestrian Excel goodness, it all becomes a
beautiful graph. You'll have to wait for the report to actually see it of
Timeline widgets are great for seeing events
and how they relate to each other temporally. Synchronized graphs such as
those used in financial
charts and by Google
Trends further show temporal
relationships and even hint at cause-effect relationships between events.
I've thought of several graphs for the annual
report that would
have a chronological
X-axis and some
piece of data on the Y-axis. It would be interesting to put a timeline of
significant life events at the bottom of a page with all those graphs. The
X-axis would be synchronised across the graphs so that I could easily see how
the birth of a child affected my reserve savings or effective tax rate.
It should be easy enough to find data for the timeline from my own memory of life events such as getting married, children's birthdays, moving to a new house, starting a new job, etc.
If I could have back the time I've spent resending emails when I forgot to
actually attach email attachments, I could spend less time sleeping and eating
and more time doing necessary stuff (thanks TanookiTravis). I need my email
client to ask me something like this: "You're trying to send an email in which
you say 'I've attached the report', but there is nothing attached to the email.
Are you sure you want to continue sending?"
In honor of the fun idea from Feltron Seven to publish personal annual
reports, I'm tentatively planning on creating my own report for 2007. I
don't want to spend much (if any) time collecting data, so this annual report
also serves as an experiment in locating data recorded about me and
aggregating it in a useful, queryable fashion.
This is the first post, in a five-month (crossing my fingers) series preparing
for my future report. The purpose is to help me flesh out ideas for content
and some techniques for creating it. As a convenient by product, these posts
will also serve as a handy scratch paper to remind me of good ideas when it
comes time to actually write the report. Each entry in this series will be
tagged with the label annual report, so they'll be easy to find later.
Now on to the first idea. Following on the heels of my recent post about
programmer context switching, and stealing Feltron's good ideas
with graphs of work and vacation, I want to include a graph showing the hours
I've worked. The graph will be a stacked, bar graph where the total bar height
indicates the number of hours I worked during each week of the year. There
will be pieces in each stack: context switching time and productive time. This
one graph should nicely highlight seasonal fluctuations in my workload and help
me see whether my efforts have reduced the overhead cost of context switching.
The data should be easy to find. I need to query my time clock database for
the total hours per week. The best bet would be to convert each data point
into RDF something like:
y2007:week_1 work:total_hours "38" .
y2007:week_2 work:total_hours "42" .
I'll get into my reasons for tentatively choosing RDF in another post, but
in this case, it might be easier to just generate the graph directly. Time
I'm working on a difficult programming task when the phone rings, "Oh, hi. I'm
doing well ..." Then when I'm done with the call, I inevitably ask myself,
"Now where was I?" When performing a mental task, one's mind has to hold
certain information (context). If that context is lost somehow, it must be
regained before continuing. The phone ringing required me to switch contexts
and then reestablish the former context when the call was done. The act of
reestablishing context is an overhead cost for mental work. Bryan Dollery
estimates the cost of a context switch at around 10 minutes. That's 10
minutes of wasted effort.
For business purposes, I keep track of which tasks I'm working on throughout
the day. Anytime there's a context switch that lasts longer than a couple
minutes, I record the changed focus so that I can bill my clients correctly. I
wrote a quick report against my time tracking application. Assuming that
reestablishing context takes about 5 minutes, here are my results for June
Total Duration : 8998 min
Unique Tasks : 80
Context Switches : 219
Average Focus Duration : 41 min
Time Spent Switching : 1095 min
Switching % : 12%
During June, about 12% of every workday was wasted to context switching. In
any job, there is a certain amount of overhead, but this seems like an easy one
to reduce. Fortunately, most of that overhead is caused by one client, so I
just need to find a way to manage them more effectively.
Too bad so many people think that a university education is mandatory after
high school. If my children show little interest in university studies, I'll
counsel them towards apprenticed trades like plumbing and electrical work.
We had a plumber and his apprentice show up today to fix some plumbing issues.
The plumber billed $67/hour and his apprentice billed $37/hour (including two
hours of drive time). I wish I made that kind of money while I was in school.
Are there many situations better than having someone pay you to learn a
On top of the high wages, these two plumbers were scheduled two weeks out. The
wages and the backlog are the market trying to persuade people into this field.
Maybe it's a Wyoming boom-effect, but a young kid needs a serious reason not to
go into one of these two fields. After apprenticeship, you could live just
about anywhere you want, set your own hours and earn a comfortable living,
leaving you plenty of time for family and hobbies. The only cost is facing a
stigma about not attending university.
I'm all for less stigma and more heeding the market.
In August 1830, a heavenly messenger appeared to Joseph Smith and
instructed him1 that, "it mattereth not what ye shall eat or
what ye shall drink when ye partake of the sacrament" and said further that the
real importance was "remembering unto the Father [Jesus's] body which was
laid down for you, and [His] blood which was shed for the remission of your
sins."2 As such, most sacrament meetings in The Church
of Jesus Christ of Latter-day Saints use water instead of wine or grape
While I was reading this passage the other night, I wondered how much money the
Church saves annually by using water instead of juice. There are almost 13
million members on the records of the Church. From my experience it
seems that about 50% of a ward's members attend sacrament meetings on a regular
basis. Nearly all of those attending partake of the sacrament which includes
drinking one small cup of water. Each cup contains about 1/4 ounce of liquid.
Sacrament meetings are held every week of the year except 4 (General and Stake
conferences). Using those assumptions, members of the Church consume about
609,000 gallons of liquid each year while partaking of the
For this calculation, we'll assume that water is essentially free. Buying
grape juice from Sam's Club costs around $5.50 per gallon (in
Cheyenne, at least). Assuming that the Church could get some kind of volume
discount, maybe it would be as cheap as $5 per gallon. That comes out to
around $3 million annually.
This doesn't include the cost of cleaning up spilled grape juice. It also assumes that there is no wasted juice. The savings might be twice as high if we accounted for the extra cups that are poured to make sure surprise visitors are able to partake of the sacrament.
Of course, the economic cost is probably the least important reason for using
water as part of the sacrament, it's nevertheless interesting to see the
unintentional savings the Church enjoys from this practice.
I'm not quite a member of the WD-40 fan club, but the stuff is pretty amazing. A couple days ago, I discovered that one of our drain pipes was leaking. I tore off the wood paneling to find the leak and noted several rotten 2x4s that I had to remove before I could access the leaking pipe.
With my trusty hammer, it was easy to remove most of the nails and wood. However, one beam just wouldn't come loose. Two nails held it fast. The first nail I cut through with a hacksaw. The second nail was too far back for the blade to reach. I pried and pried but could only get it loose about 1/4". While I was staring at my toolbox, suddenly es fällt mir ein: use the WD-40. I stood there for a minute dumbfounded. How do I use WD-40 to pry out a nail?
Eventually my brain caught on. I sprayed the WD-40 onto the 1/4" of nail that I had exposed. Then I hammered the nail back into its hole. After a few seconds, I pried with the hammer again. Now it came out about 1/2". After a few more rounds of spray, hammer, pry, the nail came out and the timber was free.
If I had been better versed in WD-40 canon, I would have known that on page 4 of 2000 Uses of WD-40 is this great proverb:
Lubricates nails to ease disassembly of pallets.
While I was writing the previous entry, my wife walked in the room with a little snack for me. That's exactly the kind of thing a business should do for its customers: "I know this isn't much, but I thought you'd enjoy it."
(Yes, that's a Disney Princess stress ball in the background. Content for another entry.)
First, let me say that I'm all for charging as much as the market will bear. If customers don't like the pricing structure they're free not to use the product. However, sometimes charging for a product or service is poor business. For example, let's compare the Google and eBay SMS offerings.
Google SMS allows you to submit searches to Google via text message. You text
466453 and Google responds with a brief, helpful result. Very cool, very handy and all for free.
eBay SMS is a similar service. It notifies you when you've been outbid on an auction or when an auction you're watching is about to end. You can then reply to the message to bid on the auction. Very cool, quite handy and all for $0.25 per auction!? As I read the service description, my internal eBay satisfaction meter climbed higher and higher. Fantasies of useful text messages zoomed through my mind. When I saw the pricing my meter sank below where it started:
Are you kidding me? That must cost you next to nothing.
Now of course, I'd rather that eBay offer the service for a charge than not offer it at all. There are probably some people out there willing to pay for eBay text message alerts, but I'm not one of them. By providing SMS messages as a complimentary service to bidders, eBay could make their platform more appealing. They would have kept my customer satisfaction meter nicely stoked.
In business, it's important to ask,
How can I show the customer my love? Often the answer is the same as with romance: small, inexpensive trinkets that say
I'm thinking about you.
Unfortunately, English spelling can be hard. And when it comes to spelling
names, it's even more difficult. For instance, in English, the name /ˈeɪdriən/
could be spelled in at least the following ways:
In human circumstances, this isn't a problem since people recognize all the
spellings and translate the written text into a phonetic representation in
Now imagine that you want a computer user to enter a name into a search box and
have the computer convert that entry into an identifier in a database. If the
database has "adrienne" and the user types "adrian", there's no match. It's
too time-consuming to enter every possible name variant into the database.
Phonetic coding algorithms address this problem. For the list of names above,
the Soundex algorithm generates the code
A365. By storing a single
phonetic code in the database and converting the user's entry into
can find the person the user intended.
There are many phonetic algorithms. Soundex is one of the
first and most widely used, but it doesn't always perform well. For example,
my sister-in-law is named Caron. People inevitably spell her name as "Karen."
Soundex doesn't help because the codes
K650 are different. In
this case, we could switch to the NYSIIS (
CARAN), Metaphone (
Double Metaphone (
KRN) or Phonix (
I sometimes encounter the misspelling "Hendricks" vs "Hendrick." By ommitting
the final "s", one confuses the Metaphone and Phonix algorithms. NYSIIS
HANDRAC) and Double Metaphone (
HNTR) still work in this case though.
For my particular application, I settled on NYSIIS because it
can be implemented in about 30 lines of Perl code and works quite well for
the names I'm interested in. However, it doesn't entirely solve the
use case I described above. There's one person in the database whose proper
name is Elizabeth but she goes by the name Betsy and another whose name is Amy
but she goes by the name Teddy.
In both cases, the problem lies with nicknames and not phonetics. It would be
interesting to develop a phonetic code which accounted for nicknames.
Perhaps by converting names into canonical names (Betsy -> Elizabeth) before
applying the phonetic code. Or maybe using the edit distance between two
phonetic codes to determine similarity. With a phonetic code like NYSIIS, this
hybrid approach could be fruitful. Some research by Zobel and Dart
indicate success with similar hybrid techniques.