We live here now.

Tim Ferriss' "Four-Hour Work Week"

I have started reading The Four-Hour Work Week by Tim Ferriss. When I’d read descriptions and reviews of the book, I formed the opinion that I already intuitively understood many of the principles at work, particularly as regards his steps of elimination and automation. Reading it confirmed what I’d suspected: I had already used these techniques and even counseled others to use them in my work as a classroom trainer and consultant. It sprang to mind a particular success story from my early software career.

I worked as a student-on-call at IBM in Toronto in 1997. I started on the Visual Age for RPG project, which entailed my comparing error messages between the older RPG compiler and the newer Visual Age RPG compiler. While they had automated the test that produced all the error messages they wanted to check, they hadn’t automated checking the messages from the two compilers to each other. Instead, I started doing that. I began with 50-page printouts: a master copy and printouts from each test run. I compared the two copies, then reported a defect when I found an unacceptable difference between the two. It took a few days to learn which differences they could tolerate and which ones they decided warranted a fix. It took me several hours to compare the printouts, and I resented the tedium. After a week, I had the thought that all successful people have: there has to be a better way.

First, I asked whether I could use e-copies of both the master copy and the test runs. They arranged for that with little effort. As I waited for that, I looked for patterns in the text I compared by hand, learning how to extract the messages from the surrounding text and how to describe meaningful and meaningless differences. Once I received e-copies of the master copy and a single test run, I started writing a computer program to load the two files, compare them, then summarize the differences, highlighting the meaningful ones as “almost certainly defects” and the meaningless ones as “probably not defects”. This gave me an opportunity to write my first truly useful programs in C, a language I hadn’t much used before, but one that I imagined would benefit me as a professional programmer. I don’t recall how long it took me, but I don’t remember anyone becoming impatient with me, so the time I spent must not have made me a bottleneck.

The first day, I used my new program to on the next test run, but verified the results by hand. I noticed that my program took about 30 minutes to run: I had an old computer, I didn’t know how to write particularly quick programs, and don’t forget the test runs amounted to 50 printed pages. At first, I looked around the office while my program ran for something to do, as I didn’t have access to the internet on my computer. I flipped through a few manuals, including a C manual that I thought might help me. That day I processed two test runs, the same as any other day, but noticed that my manual checking went quicker, because I could check the meaningful differences first, then the meaningless ones, then double-check the rest of the document to ensure that program didn’t miss any defects. To my delight, it performed more than well enough for me to start trusting it within a week.

Now the time had come to harvest my productivity crop. I collected that day’s test run and a new master copy, loaded them into my program, ran it, then wandered around the building, knowing I had about 30 minutes. I hadn’t realized the size and complexity of the old IBM building in Toronto. I began to understand the need for its intricate room addressing system, right down to numbering hallways, odd numbers running north-south and even numbers running east-west. I walked back to my office after about an hour of wandering to look at my program’s result. I reported two defects, then wondered what to do next. I had to wait for the next test run, and they wouldn’t run one for another couple of hours. I wandered the building some more and stumbled upon something of interest: a dart board in the cafeteria.

I started playing darts.

In less than two weeks, I’d gone from a terrifically tedious job checking two 50-page documents to one another by hand to IBM paying me roughly $150/hour (as a starving undergraduate student!) for about one hour per day, with seven hours of playing darts, reading, or generally relaxing. All this by finding an ineffective work process and streamlining it with a little elimination and a little automation. I had gained some relative mobility, as I only needed to spend about an hour a day in my office, reporting defects or fixing my test program.

Now I need to confess something: my program did not operate perfectly. Every two weeks or so, I’d notice something my program missed: a difference that my program interpreted as meaningless that I needed to report as a defect. This meant that, every so often, I reported a defect later than I could have. I was performing at far less than 100% efficiency. Funnily enough, it did not matter at all! I didn’t understand the theory at the time, but I experienced it then: the project had a bottleneck somewhere else in the system that moved more slowly than I reported defects, so I could generate no extra value by reporting those defects more efficiently!

Imagine that: producing better results wouldn’t have mattered at all, so it didn’t matter that I produced my results less than perfectly efficiently.

Since I didn’t understand bottlenecks at the time, I felt bad about “cheating” and added more rules to my program to handle these increasingly subtle distinctions between meaningful and meaningless differences. The resulting program did work better and did automate my work even more, allowing me to go from one hour of work per day to closer to 45 minutes; but if I hadn’t been refining a skill I would use later to make a lot of money, then I would have looked back on that as a waste of time. Had I known any better, I might not have bothered at all, and simply played more darts!

Long before I started reading The Four-Hour Work Week, I managed to use some of the principles he describes to turn an $18/hour job into a $150/hour, one-hour-per-day job where I got to play darts, read, and otherwise relax most of the day. I didn’t wait to perfect my time-saving system; I just started using it as soon as I reasonably could, even though it cost me extra time for the first week! Since then, I’ve managed to combine the goal of mobility with the principles of elimination to retire at 34 on passive income streams worth 1.5 times my family’s essential living expenses. You can do it, too, and I recommend The Four-Hour Work Week for beginners to read to help form their vision of a new life, and then to re-read a year or two later to refine your approach to freedom from the tyranny of tedium.

I have recently read Robert Sawyer’s latest release, Rollback. Overall I enjoyed the book, but after I finished it, I realized how much different it was from most of his other work. Books like The Terminal Experiment or Factoring Humanity are true mysteries: high-tension, usually involving crime with a scientific background. I didn’t feel the same tension in Rollback as I did reading most of his other work. I want to be clear: I enjoyed Rollback, but simply differently than I’ve enjoyed Mindscan or even the Quintaglio Ascension series. While the effect Rollback had on me was different, two key elements of Sawyer’s work were familiar, and I enjoyed them.

First, the philosophical question raised by his scientific theme: rejuvenation in the strictest sense of the term. In Rollback, the ultra-wealthy (wealthier than “mere celebrities”) have access to gene therapy techniques that return the cells to a younger state. Over a period of a few months, these younger cells return the body to a younger state, that of the time soon after the body has matured. This allows those near death to extend their lifetime by 60 years or more, but also to regain their youthful quality of life. Rather than have his characters gaze at their own navels over this question, Sawyer invites the reader to consider the possibilities, while allowing his characters to make decisions and get on with the business of living. I prefer this to the typical morality play in which two characters represent each side of the argument and spell out what the author believes through their dialogue and actions. I don’t have much need for a preacher these days, so I’m quite happy that Sawyer chose not to preach.

More personally, much of this novel takes place in Toronto, with a little in Winnipeg. I freely admit that one thing that attracts me to Sawyer’s work is that so many of his stories take place in Toronto. For me, the story comes more alive when I can actually visualize the setting, rather than having to imagine it. This is the first time reading such a story since the move to Dauphin, so thinking about places like Senlac Av. and Park Home Av. brought on even a feeling of nostalgia. This certainly intensified my feelings and helped me enjoy the book even more. Now that we live in Dauphin, the mention of Winnipeg towards the end felt almost like a nod in my direction, as strange as that sounds. I wonder how long it will be until those Toronto streets and landmarks become unfamiliar to me. It’s already been a month since we’ve ordered from a Pizza Pizza.

I enjoyed Rollback, even though it wasn’t quite was I have grown accustomed to reading from Robert Sawyer. I recommend it, unless you would be dissatisfied with the absence of a murder mystery.