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.
Tags:
