Read Next

A Short Trip to Alaska

One night, while in the RV working on SETT, Todd suggested a trip to Alaska. I said I'd be interested in it, forgetting that in our group of friends, this low level of commitment basically always results in a trip happening. A couple weeks later I bought a really decked out 2001 KLR 650 motorcycle specifically to drive from San Francisco to Alaska, bought a knife, and stopped shaving my beard. That was about all I could think of doing to prepare for the trip.

Our departure date came a month later, and five of us met in downtown San Francisco with our bikes ready to go. Without much fanfare, we headed North, towards Canada.

By the time we stopped for gas for the first time, I had decided to turn back. At the high speeds we prefer to travel at, my bike was a little bit wobbly, probably due to the knobby tires and panniers. This could be fixed with a $100 fork brace, but there was nowhere to buy one and no time to ship it. Beyond that, though, I realized that I don't really enjoy long distance motorcycle trips. You can't talk to anyone, your seat is about as comfortable as a bar stool, you can't have snacks or water, and you can't change the music or podcasts on your ipod. Besides that, I wasn't feeling great about the sharply reduced hours that I'd be able to work on SETT. So I turned back.

Initially after turning back, I didn't plan on going to Alaska at all, but I had already bought my return ticket from Anchorage, so the cost of flying up for a few days was cut in half. I called around a couple motorcycle rental shops, and Nancy from Alaska Motorcycle Adventures offered me a great deal on a BMW, along with a really great route that she suggested. I bought my one-way plane ticket minutes later.

Guest Post: Shanna Mann on Systems


After a comment I made about my documentation binder in a previous post, Sebastian asked me to share my own system with you all.

Be regular and orderly in your life so you may be violent and original in your work. ~ Gustave Flaubert

My organizational premise is this-- if your recurring tasks are fully optimized and automated, you have more RAM to devote to novel tasks and projects.

Novel projects should be well documented. If they become routine, it's an easy starting point from which to optimize. If they don't, they may still be useful in the future. This is especially important because optimized systems experience entropy, and needs regular overhauling, which is actually what I was doing when SM asked me to expand on my system.

I like to overhaul about twice a year, but in practice, I overhaul when the drag of changing circumstances has aggravated me to the point where I either have to overhaul my system or abandon it. I don't find that “fixing as you go” is a viable strategy. Tweaks are fine, but there comes a time when you have to tear down and start anew, and you'll never get away from that.

Rendering New Theme...