One lingering regret is that I never learned to ollie. After I got comfortable skating again I set my mind to learning how to ollie. Last summer I made a small bit of progress, and this summer I’m hoping to finally nail the damned thing.

This weekend I shot some footage of myself practicing. Then I wanted to use that footage to make a little movie. For me, on my Mac, that means iMovie.

I’ve had some modest successes with iMovie in the past, but I’ve never really understood it. The interface is confusing. I’m sure they are trying to make things easy, but it’s like there are so many things to make easy that they make it crazy instead.

I had two and a half minutes of footage of me flubbing around with the skateboard. What I wanted was to grab two portions of the video (where I was actually practicing) and join those together with a modest transition. Then I’d add a title screen and upload it to YouTube to embarass myself.

Simple, right?

First I had to figure out how to get my video out of Photos and into iMovie. I imagined that I could just export the file and then import it, but that seems like The Hard Way. Apple ships the computer with both programs. There must be a Better Way. Off to Google I went, which is ok because I’m basically a Professional Google User (uncertified). Much to my consternation, the recommended way to get your movie from Photos to iMovie is… to export it to a folder and then import it. Stone knives and bear skins!

I did the export/import and created a new project in iMovie. That part went fine. I had a project, I imported my footage, and then I started to make a title. That took a while to figure out (despite the fact that I’ve done it before) but soon my title was in place. Ah, but I needed to split up my footage into two parts. How do I do that? More googling. It was easy but not obvious. I finally figured out how to split it up, but then realized that I have the opportunity to have a cold open on my video where I walk up to the skateboard. So this will be great. Cold open to establish I’m doing something with a skateboard, then title, then my two clips. Ah, but what would be really cool is to have the background audio going over the title sequence so there is continuity in my little story. Googling again, I find out how to do this in iMovie 11. (Later I find out I’m on iMovie 10.) I can’t find the option I found with Google, but poking around in the right place helps me figure out that I can detach the audio. Perfect! This is great. I mess around a little more and then I have a cold open, a title, and then I’m on the skateboard. Something is not quite right though. Ah, the title card just pops in. There is a tiny effect but no smooth transitions. I see the option for transitions and pick the simplest and put it in place. Now everything is set up! I sit back and watch. Something is still wrong…. Ah! The audio is out of sync. Probably by the amount that it is offset during the title sequence. Or maybe I just dragged the wrong slider and screwed something up. I really don’t know. It’s all voodoo at this point. I have no idea what is going on and no idea how to fix it.

I gave up. I wasn’t pissed, just disheartened. I could see nothing but frustration in my future, so I stopped.

And this is The Hump.

The Hump is this point on your learning curve, usually after some early success, where you decide that the effort just isn’t worth the reward. This is the point where opportunities are lost, where you talk yourself out of victory, and where dreams die.

Seriously.

Look how close I got to success before I gave up! This is common. And then there was my bad attitude. I felt like I was being held back. I blamed the software. I blamed Apple. It wasn’t until I realized this was just The Hump that my attitude started to change. I stopped thinking about how messed up the situation was. I started to think about how I was going to get my video done. I went from being indignant to resolute. I went from being pissed at tools to being pissed that I was letting little things get in my way.

I tossed out the crappy work I’d done earlier and stepped back. I started to reframe the problem. I realized that since I now knew how to split footage, I could at least start by breaking things up into clips. With that done it was easy to delete the cruft. I was left with a series of scenes that were keepers. That formed the backbone of my movie. Instead of trying to build the movie from the front to the back, I created a scaffold along the critical path of what I was trying to do.

I eventually got my movie done. It took about an hour more than I thought it would, but I shipped. (WARNING: Super-boring single-shot video of 42 year-old legs mostly not ollying. My wife panned it, it’s that boring.) The movie isn’t the exciting part. Beating The Hump is the exciting part.

I worry that The Hump is this quiet killer of potential engineering careers. It’s great to see the energy behind programs to encourage people to learn to code, but it’s not enough. You can show people how to code all day long and all you’ll ever create is a bunch of people who can follow instructions. That isn’t what programming is. Software is a particularly cruel medium. You don’t just get over The Hump when you learn how to code. The act of building software is a non-stop series of Humps. Even worse, software eats problems. That means today’s hard problems are always a little harder than yesterday’s. Meaning the Humps never stop coming.

May you turn your Humps into moguls.

Ah, the Hyperloop. Holy crap, it even has its own Wikipedia page.

If you have no idea what I’m talking about, that’s okay. No one else does either. Which is why I’m writing this post. Something as vague and amorphous as the Hyperloop brings out all of the kooks and the cranks, including Yours Truly. This whole episode reminds me very much of the “Ginger” hysteria from 2001.

I have no better idea than you what the damned thing is. All I know is that listening to Elon describe it, it started to sound like a crackpot idea I had many years ago. Ordinarily I keep my mouth shut about such things (high school taught me that), but every now and then it’s fun to share a goofy idea and this seems like a great time to do it. Ready? Cool!

Uh… so… this is where you flat-Earthers are going to get really pissed. Sorry. Here’s a diagram of the Earth:

Yeah, I know. Art school really paid off.

The Earth has this curve to it, you know? And if you make a straight tunnel long enough, eventually you’re going to come out the other side. If you shoot straight through the planet you’ll hit molten lava or something. Not awesome. But if you limit the distance you’re trying to go, your tunnel can stay safely inside the earth’s crust, as shown.

Elon talked specifically about a connection between Los Angeles and San Francisco, so let’s draw that:

Aside from the startling reality of the drawing, you’ll notice some arrows labeled ‘g’. Those indicate the direction that gravity is pulling from different points along the tunnel.

(For some reason the tunnel I drew extends from the Hollywood hills to somewhere around the Mission District.)

What’s awesome about this tunnel is that it is downhill from both sides. If you are wondering how a tunnel can be downhill both ways, imagine walking through the tunnel in the picture. At first, it’s downhill. As you walk further, the tunnel has a different angle relative to the Earth’s center of gravity. Over more and more distance the angle changes enough that by the middle of the tunnel things are flat, neither downhill or uphill. Gravity is pulling straight down. Then as you continue forward it’s uphill to the other end of the tunnel. While the tunnel seems like a straight line to you, from the perspective of gravity it is shaped more like a half-pipe. In other words, the tunnel is downhill at both ends and is uphill in both directions from the middle. As Einstein once said, “Gravity be crazy, yo!”[1]

Anyway, I had the basic idea for a tunnel that you could hurl things through. There were some things I wanted to know. Namely:

• Would the tunnel stay inside the Earth’s crust?
• How fast could you go, with no additional energy, ignoring friction?
• How long would a trip take, with no additional energy, ignoring friction?

It’s about time we had a diagram.

Of course this is just a conceptual diagram to help think about the problem. The Earth is HUGE and this triangle would be absurdly narrow and deep if we tried to keep things scaled in any way to reality.

The Details

Remember that part about Earth having a curve to it? That turns out to be a bit of a hassle. The curve is important to this problem, but the Earth doesn’t have the same curve everywhere. Seriously, this is the kind of thing people write dissertations about. After many rounds of trying to get super-accurate numbers, I opted to go with “cocktail napkin”-quality calculations. This means I’m using the median radius value of Earth that I found online, not the actual value for the region between LA and SF. Since this is not a project proposal and I am just some random guy on the Internet with a blog, I hope you’ll allow me this indulgence. My calculations are in the notes below, after the end of the post.

The key piece of information I wanted to know was ‘h’, the depth of the tunnel at the mid-point. That is because I wanted to know how fast you’d go if you were to slide down this tunnel through the mid-point. I also wanted to know if this tunnel would stay within the Earth’s crust over its entire length.

The number I came up with was about 6 km. That’s deeper than I expected. The Earth’s crust turns out to be between 5 km to 70 km thick depending on where you are. Since I know absolutely nothing about geology, I’m just going to pretend that the crust is substantially thicker than 6 km in the LA to SF area.

Honestly, given this “median radius” I’m working with, I wouldn’t be surprised if my numbers are way off. Earlier numbers, where I was trying to be more accurate, put the depth at more like 2 km which is borderline practical. It’s also way more boring, because the greater the depth, the faster we can go…

The depth of the tunnel’s mid-point tells us the velocity for any mass allowed to fall into the tunnel. This is in an imaginary scenario where there is no friction or air resistance and no energy is added to the system. The mass is just “dropped” down the tunnel. At first you’d start off slow, heading down a 4% grade, but my numbers say that you’d be going about 767 mph (~ 1234.5 kph, interestingly) by the time you reached the mid-point of the tunnel. That’s around the speed of sound. It’s also in the neighborhood of “twice as fast as a plane”, if you consider typical commercial airspeeds.

I did not end up calculating the trip time. See “Problems” and the calculation notes for more on that.

Interesting Properties of Tunnels

Tunnels are “immune to weather”.

Tunnels work well with maglev. I built a model maglev train for a project in grade school. It didn’t work too well. My cars wouldn’t stay on the track. The permanent magnets I was using would flip my cars over. In a tunnel that doesn’t have to happen – you have more surface to use than just the ground.

If you build your conveyance (space pod, trolley, what have you – I’ll use “car”) to work with the tunnel you can have something that never derails. Further, despite those action movies where people dive out of airplanes to save other people who were thrown out of airplanes, falling bodies tend to fall with uniform motion. That is to say, if you pushed a car down this tunnel and then pushed another one down the tunnel shortly afterward, they “never crash” into each other because they’re following the same path and obey the same laws of motion. The number of cars you could have in the tunnel at any one time is determined by the length of the tunnel. If you had a tunnel going in each direction you could keep a continuous loop going so “there is no waiting for a specific departure time”.

Problems

A few times above I oddly quoted a term or phrase. Those were various descriptions that Elon has used. Just because something matches a description doesn’t mean it’s the same though. Only some of this comparison stands up to close scrutiny. Particularly problematic is the matter of speed. I haven’t calculated the total trip time yet but the only way I could get my trip time under 30 mins is if the average speed for the entire trip was the maximum speed I calculated at the mid-point of the tunnel. (For the curious, the trip at that maximum speed would be about 27 minutes, “under 30 minutes”). Also, friction and air resistance are things that I’ve completely ignored. The final major problem is cost. He has estimated a $6B project cost. Can you tunnel nearly 550km on $6B? Maybe. I really don’t know.

OTOH

This whole scheme I’ve described is based on zero external energy and zero initial velocity when cars enter the tunnel. When you add in the costs of friction (even if you do maglev) you have to have some kind of external energy source to at least make up for the losses. And if you’re going to add extra energy to the system, you might as well add enough to make it interesting. Maybe even get the speed up and bring the travel time down. I’ve heard some people talk about rail guns. That sounds interesting.

Oh, and one other thing I can’t help but point out: Elon used the phrase “average speed”. You either raised your eyebrows at that or you didn’t. I know I did.

What’s the Point of All of This? Is This the Hyperloop?

Wouldn’t that be awesome? But no, I’m sure I’m way off the mark. After all, I thought “Ginger” was going to be a flying car or jetpack. You know, something cool. For the Hyperloop, the similarities to my idea were too good to pass up. I had to make the comparison. There are probably dozens of other unrelated schemes that could fit the description Elon’s given so far.

I guess the point is that we can all dream up interesting ideas, and we should play with those ideas more, even if we’re not Tony Stark. I used to do this all the time when I was 11 or 12 years old. Why don’t I do that anymore? Playing around with this has been fun!

(A nice conversation about this has popped up in a friend’s Google+ stream.)

—-

Cocktail Napkin Calculations

The numbers I started with (all figures approximate):

Find h:

h = r – L

To find L, I needed to know μ, and to know μ I needed to know θ, which is the angle between the two cities from the perspective of the center of the Earth. This is where having super-accurate curve info would have been handy. But oh well, on we go with the median radius.

θ = s/r = 0.0863 radians = 4.945 degrees

μ = 0.5 θ = 2.47 degrees

L = r * cos μ = 6366 km

h = r – L = 6372 – 6366 = 6 km

—

Maximum velocity v:

v = sqrt(2gh) = sqrt( 2 * 9.8 m/s/s * 6000 m) = 342.9 m/s = 1234 km/h = 767 mph

—

Time for trip if at max velocity: t = 550 km / (1234 km/h) = 0.445 h = 26.7 mins

—

Slope of the tunnel at each end would also be 2.47 degrees.

Grade = tan(2.47) * 100 = 4.31%

—-

I’ve ignored the gravity of the portion of earth above the tunnel. The ideal shape would probably have some curve to it. Speaking of which, “hypocycloid” sounds a lot like “hyperloop”. Coincidence? Probably.

—

I didn’t calculate the travel time through the tunnel because the angle of gravity changes as you go which is different than a first-year physics velocity calculation where g is always straight down. This started to look like a path integral so I ran away! The Gravity Train article suggests that on Earth this time is always 42 minutes, but I’m not convinced that this is the same problem, as the gravity train notion involves taking some optimal path deep through the earth. Clearly, I have homework to do. If there’s an easier solution or you’re handy at this kind of thing, get in touch. Thanks.

Update: Alan Eliasen, creator of the lovely Frink programming language, shared a program that calculates point-to-point travel times through a more realistic model of the Earth. He’s seeing a 38 minute travel time rather than 42.

We work with a small but quite tangled system. The system itself is only a few years old but contains many technologies and bears the scars of several smart but inexperienced people learning how to design as they went. I won’t articulate the details of the bug we were experiencing but I will say that it is something that recently appeared and was troublesome but non-critical.

The difference in our two points of view became apparently very quickly. My desired approach was to try to pin down the bug, deconstruct it to the point of understanding, and then apply a fix. My coworker’s approach was to make a well-educated guess about the cause of the bug and apply a refactoring to our codebase that would address the anticipated problem.

His reasoning was that our codebase was too complex to spend time trying to understand it in detail, and in the worst-case scenario we would still have completed a useful refactoring that improved the quality of our codebase. I found this a bit hopeless. Is software really so complex that we as programmers now have to act like doctors – diagnosticians – making reasoned guesses about the world around us? Is there no more engineering?

10 or 15 years ago I would have considered his approach ridiculous. Now I’m honestly not sure. Modern software systems contain so much abstraction and layering that it is really hard to judge the level of effort that will be involved in addressing any one problem.

So what option did we choose? We guessed and did the refactoring. I don’t think I would have agreed to that with just any pair partner, but this particular coworker is a very productive programmer. He had a clear path forward and a clear rationale. And one thing you don’t do with a productive programmer is get in their way.

Did it work? No. I almost want to say “OF COURSE NOT!” but that would be unfair. It could very easily have worked. What did eventually work? A pair sitting down and tracing through the application stack with gdb. And even that has only located the approximate location of the error. We still haven’t solved the problem yet. But we’re much closer.

This morning I stumbled across this post which comes painfully close to what I had in mind. Painfully because it heads in the right direction and yet is still thinking in a limited, old-media way about the nature of content.

We punish the value creators on the Internet. We should reward those who add value to the network. Instead, the more value a site adds to the network, the more fees the site owners have to pay.

What if the internet worked exactly the opposite from the way it works now? Instead of charging someone like YouTube for bandwidth, carriers would indirectly pay to carry that bandwidth. Consumers would still have a flat-rate ISP subscription, with part of that money being distributed to content providers.

In this way, users would quite literally vote with their attention. This is not the same as your cable company deciding what channels to carry. In this scheme, bandwidth is the only commodity that carriers need concern themselves with. Specific details of content would not matter. Consumers buy bandwidth. Then they hit the sites they like. Those sites receive a portion of the money collected from consumers. This is not on an individual basis; it is aggregate. So if 20% of my ISPs bandwidth went to Youtube yesterday, so did 20% of the allocated money for that day. From Youtube’s perspective, the bandwidth is free and they make money for hosting the content that the Internet values. Ditto for Flickr, Google, Gmail, the New York Times, or any other site that provides value.

This scheme would work much better than micropayments, mainly because it is dirt simple. Certainly people would try to game the system, and there will always be low-value websites and services which might get some trickle of bandwidth. But over time the wrinkles would be ironed out and the sites and services that create value would be the ones that consistently earn money.

Beadrooms or not, the house has gone unsold. I’m sure it hasn’t helped that the owner is selling it himself. I think the old saying about having a fool for a client applies to more areas than just law.

I realized today that this guy’s For Sale sign is a brand. It’s not working for him, but it is definitely a brand. After all, what is a brand? It’s a tool that gets potential customers to stop thinking. Seriously. If you’re Coke, with an insanely huge brand and market presence, all that your brand does is get people to not think about alternatives. Smaller brands are a variation on this theme.

So here’s this guy with his For Sale brand. It’s there every day, rain or shine. And people have stopped thinking about it because it doesn’t change. It’s a brand. It’s sort of sadly fascinating that this guy has accidentally created something many companies pay a lot of money trying to achieve.

Worse, I think the handwritten “beadrooms” sign had more draw.

So Kent’s post is titled “Hit ‘Em High, Hit ‘Em Low“, and in the post he describes a debugging technique he calls the Saff Squeeze. It is very similar to a technique that I was taught when I was a junior programmer by my good friend and mentor John Petts. Up until now I’ve just called the technique “break it on purpose”. If I knew we were honoring people with names for things I would have given it a better name, like “the Petts Awesomeness” or something. Still, a name would be good, and Saff Squeeze isn’t really working for me (no offense to either Saff or Beck). If we continue Kent’s football metaphor we might just call it “Intentional Grounding”, but I’d prefer to think of it as “Injection of Failure”.

In Kent’s post he describes the technique in unit-testing and refactoring terms: You have a test that doesn’t work and you can’t spot the problem. So you inline your code-under-test which allows you to move your assertion(s) up through the inlined code until you find the error.

This technique is not limited to unit tests and doesn’t require refactoring. It does require a willingness to break things. That’s about it. Here’s all there is to it:

If you have an error in your code but you can’t tell exactly where that error is, create your own error that you understand and try to place it in the code before the error you’re hunting for.

When I was first taught this trick I was a C++ developer trying to troubleshoot a complicated build that had started failing after I pulled in code from another project. But this technique works great in any complicated system. I’ve used this technique recently to diagnose problems with Django, a Python-based web application framework which can sometimes generate very mysterious error messages. But the place that I’ve had the greatest success with this technique is diagnosing Javascript errors in the browser, where development is often like eating noodles with one chopstick.

The one refinement to this technique that Kent doesn’t mention is to use a binary search to find the bug. If there are a 100 lines of code and you know the error is in there somewhere, inject your own error right in the middle of that code. If the error message or program result changes, you know that the bug lives in those last 50 lines. Otherwise it is in the first 50. Then you repeat, moving your injected error halfway through the remaining code each time, until eventually you find the offending line(s) of code.

Several years ago I finally got tired of this. I wanted to figure out how to be someone who could be on time. The answer I found isn’t glamorous or fun, and it may seem obvious to some people. It wasn’t obvious to me though, which is why I’m bothering to write about it.

Have you heard of the Powell Doctrine? If you look it up you’ll find a bunch of boring statesman-speak with bullet points, but the best and most concise summary of the Powell Doctrine that I have heard is this:

You go to war with overwhelming force.

This turns out to be the approach I took. I decided that I would be ridiculously early for appointments. If the doctor expected me at 10 o’clock I would be in his lobby at 8:30 or 9. I’d bring a book and wait it out. My overwhelming force was time.

This has worked remarkably well for job interviews. I don’t necessarily show up for the actual interview an hour early (which might seem desperate or at least odd), but I am not averse to sitting in the company’s parking lot for 45 minutes beforehand. If the meeting or interview is important enough the time is totally worth it.

A lot of common advice about punctuality talks about being 15 minutes early for your appointments. That shit just doesn’t work. Most people are smart enough to do the math and say “oh, I have 15 extra minutes so I can stop at Starbucks”. Then they stress out when it takes 12 minutes to get their coffee instead of the 5 minutes that they’d convinced themselves it would take. Since they were already running 10 minutes behind, big surprise, they’re late.

To make this work you need to stick with the term “overwhelming force”. If an hour isn’t early enough, try three. Seriously. If the appointment is that important, why not? Bring a book or your iPod or your laptop. Or convince a friend to come along and keep you company. Do whatever it takes to create that overwhelming force. Absolutely nothing short of death, serious injury, or a kidnapping will prevent you from being on time for an appointment if you leave for the appointment hours before any sane person would.

This isn’t just idle talk. I did this recently when meeting a prospective client. I was meeting someone in a new part of town that I wasn’t too familiar with and I was taking public transit. I planned my trip so that I would be in the area an hour early. All sorts of things went wrong that morning: I got out of the house late, I missed my bus and had to walk a mile down to the light rail station. Then I missed the first train and had to wait for another. Finally I was on the right train, heading in the right direction but incredibly late! The train was taking far longer than I expected. I finally got off the train and walked the rest of the way to the meeting, where I was about two minutes early. I felt like a total failure, but I was on time. If I had planned on being 15 minutes early I would have blown the meeting and probably missed out on a new client.

I should say that I don’t do this all the time. Just like a nation shouldn’t always be at war. But when force is required, you want to go all the way. I’m not always on time for every appointment in my life. But I know how to be on time when it counts.

Instead of digging through bookmarks (which I wasn’t doing anyway) I’d google for a term that I remembered had given me the results I wanted in the past. If that sounds like more work than using bookmarks, let me assure you that it isn’t. Once you collect a non-trivial number of bookmarks you have to categorize them and remember that hierarchy. Which is directly equivalent to just remembering what you typed in. If you think of your bookmark category and bookmark name as a key to lookup your desired results, then you can think of your search term in the same way. And generally your search term is easier to remember. In fact, you don’t even have to remember it: For whatever reason, when I find myself googling for a piece of information I invariably type in the same query or nearly the same query that I typed in last time. Even if months or years have transpired. When your “key” is so directly and humanely tied to what you want it works so much better.

My google-not-bookmarks strategy has served me well for about 6 or 7 years. Lately though, I’ve noticed that Google results have begun to fluctuate dramatically from day to day depending on the topic and the query I provide. So while my search terms haven’t changed much, the results have changed. Lucky for me that my browser remembers (and highlights) which links I’ve already visited, otherwise this system may have broken down for me a long time ago.

I don’t think anything crazy has happened at Google. Instead, the things I tend to repeatedly search for are in a narrow niche of geekdom. I’m sure this has been a problem for a long time for people who regularly google more popular topics. Only as the size of the Internet has increased – and therefore the size of the searchable content – has my neck of the woods finally been impacted.

To some extent this constant change is a good thing. Google offers a hybrid of fresh content and relevant results. So you can watch a topic for changes. You can even google yourself. In fact the how-to-blog crowd widely recommends that you google yourself often to see what people are saying about you online. (They don’t mention how unsatisfying that act is when no one knows who the hell you are and therefore no one is talking about you. Still, were someone to talk about me, Google would tell me all about it.)

On the other hand, I’m losing my auxiliary brain a little bit more every day. For instance, I sometimes have trouble remembering how to make a tarball. I don’t like the two-step process where you make a tar file then you compress it. Instead, I like a nice clean one-liner. Modern tar provides a compression option and will kick out a tidy *.tgz file for you. If only you know the magic command-line options and parameter sequence to get it to do that. Sadly, I never remember. So this is something I google for fairly often. Just in the past week I’ve had to google for this twice. And I know I googled for it a month or two back. And each time found markedly different results. I don’t even know where the site I found a few months ago is, but it isn’t in my search results anymore. At least not on that first page. Sadly, that site from a few months ago had the best instructions for making a tarball.

I guess I should have bookmarked it.

Looking back on my career up to this point, the projects that have entertained me most have been ones with blank slates, using new, cutting edge technologies. That is very common with programmers; we like to be entertained by our work. But entertainment alone turns out to be a poor reason to take a project. I can see now that the projects which have stretched my problem solving skills the most have been the nasty legacy projects. The ones where I’m asked to do the impossible. To make things happen that otherwise couldn’t.

Most programmers run away from legacy code and projects. Not me. Legacy code is like sculpting clay to me. And lately I’ve been wanting to sculpt something. Something mighty. That’s right, I said mighty.

I want the gnarly project. The one with spaghetti code that has passed from programmer to programmer over the years, both competent and incompetent. The one that has been ported to 5 different platforms and/or languages over 20 years. The one that other programmers have looked at and thrown their hands up and run away from saying “Fuck that“. The one that the entire company is running on and dare not be touched for fear of taking down the business. The one that is holding everyone back and requires mindless redundant data-shuffling by humans just to be kept happy. The one that you’d replace in a heartbeat if only you could pull it off.

That’s what I want for Christmas. Someone tell Santa.

Not being big on flying, I headed over to Amtrak to see how many arms and/or legs they wanted for a ticket.

For the most part I have no real problems with Amtrak. They are running an under-appreciated and underfunded service in an almost non-existent market on tracks they don’t own and have no control over. Many people I’ve talked with over the years say they long for a European-style rail system where train travel is widely available, simple, and popular. Amtrak will never be any of these things, sadly. There’s just too much that needs fixing. But I digress.

Amtrak has a decent website with features and functionality that have steadily improved over time. Like any other travel-industry website there is a small learning curve, but for the most part it is easy and pleasant. That pleasantness even extends to the check-in procedure at the station. If you order your ticket online you can pick it up from a simple automated kiosk that will print out a neat little ticket that is a classic example of how forms should be designed. With it’s classic 50’s styling you’ll feel like Cary Grant in North by Northwest. Bring your own Eva Marie Saint.

Don’t be fooled though. The website, the modern kiosk, and the wonderful ticket design all hide a secret that you probably already know: Amtrak is fucking insane. Like ‘Kramer doing stand-up at the Apollo’ insane. Like Cameron Diaz in Vanilla Sky insane. I think you get my point.

Still, the train is the train. Biggest thing I like about the train? It will never, at any point, fly at 30,000 feet. Call me crazy, but I’ve got a thing about sitting in a fuel-filled aluminum tube 6 miles in the sky. I’m sure it’s just me. Whatever.

So I went on the Amtrak site, punched in PDX to CHI, selected June something-or-other for the dates, and presto, here’s what they gave me:

Do you see what I see?

In case you can’t read their time table, this lists four possible trips that I could take to get to Chicago. So far, so good. The first trip looks best: Portland to Chicago, straight through. No muss, no fuss; $245.

The next two are a little more complicated. I can take the train to either Seattle or Spokane. Then I get to dick around for a while before catching a connecting train to Chicago. No savings to be had here. In fact one is mysteriously $26 more.

And then comes my favorite, trip #4. It’s a chance to save $25! For clarity I’ll describe the itinerary:

• I take the train from Portland to Sacramento.
• I take a bus from Sacramento to Stockton.
• I take another train from Stockton to Bakersfield.
• I take the bus from Bakersfield to LA.
• I take a final train from LA to Chicago. (Assuming I made my connection in LA. Trust me, I wouldn’t.)

So to sum up, I take trains and buses 1000 miles south, then I take a train 2000 miles northeast. Eventually this gets me 2100 miles east of where I started. Just like Pythagoras said, right?

Here’s the stats:

• Total distance: roughly 3000 miles
• Total time: approximately 66 hours
• Total savings: $25 (No, not priceless. Sorry.)

Why the hell would Amtrak even suggest something this inane?

Clearly they are taking the Traveling Salesman problem way too far. Actually, I take that back. I have no idea what they are doing algorithmically over there. The real problem – from a user standpoint anyway – is that they aren’t filtering well.

There are very few parameters to this problem: My needs are simple and specific; their abilities are limited and finite. As far as I’m concerned, there should be no more than three possible trips presented when the parameters are so few. Why three? Because there are only three factors at stake that either customers or Amtrak care about. What are they?

1. Price
2. Time
3. Quality

Notice I say “no more than” three trips. In this particular case there should only have been two shown to me. Let’s work through it:

Right away we see that Trip #1 is priced lower than Trip #2. Notice that Trip #2 takes almost 4 hours longer. And it has a connection. Connections equal risk, and risk equals lower quality. So Trip #2 is out.

Trips #1 and #3 are the same price, but Trip #3 shaves about an hour off the travel time. The quality is lower because there’s a connection, but it is only one connection and it is train-to-train. I’d keep this in the list. You never know who wants to save that hour.

Finally, Trip #4 is cheaper than any of the other trips, but it is over 20 hours longer!! If that isn’t enough of a reason to shit-can it, there are four connections, alternating between trains and buses. Throw in a plane and some pillows and you’d have a John Candy movie.

Wait.

Those aren’t pillows!