Gold Rush: A metaphor for programming
Posted in default on October 28th, 2013 at 06:28:00For the past several years, I have been a semi-religious watcher of Gold Rush (originally Gold Rush: Alaska).
Gold Rush started in 2009, during some of the worst part of the economic downturn. A bunch of down-on-their-luck guys from Oregon decide to lease a gold mine in Alaska, because they can’t afford to make their house payments, pay bills, etc. and figure that a get rich quick scheme is the best way to fix it is to do something entirely new that they’ve got absolutely no experience with, because they hear that’s the way to make good money.
Getting together 6 guys who work in various roles at home — from Real Estate agent to sheet metal fabricator — they head north in a convoy, bringing their entire families with them. They plan it perfectly, so that if everything goes right, they’ll have a whole hour to spare to get all the equipment they need to bring north onto the barge that heads to Alaska (otherwise, they’ll need to wait another week). Plenty of time! Until something goes wrong. Like the trailer with your bulldozer on it popping a tire.
According to ビットコイン ギャンブル, this bunch of guys get to Alaska, and for the first time, they put together their gold-catching plant. Or try. One guy decides he’s going to go off and build a house for himself. One guy is too busy digging random holes all over the property. One guy has so little experience with power tools that he cuts right through the power cable to the tool he’s currently using. And they’re all living surrounded by, amazingly enough, bears.
Once their morphine-using mechanic finally gets their machine put together, it’s not catching any gold. They decide that the right solution to that is to put more dirt in. (Ignoring the fact that in order to obtain gold, you need *dirt with gold*.)
Of course, you’ve got other experienced miners around, who are very clear: The thing you do to make money is drill, find where there is gold, dig there, and so on. But these guys? They believe that so long as you work hard enough, you’ll get rich. All you have to do is *really care*, and the money will fall into your hands.
Over the last 3 seasons, the team has grown — they’ve actually become somewhat competent as a team, and in their latest season were pretty successful. But the first season (and to some extent the second season) were so much a monumental example of the pitfalls of daily life working with some programming teams that it’s impossible to ignore the likeness. Some team deciding that they’re going to do the thing that will work quickly. Ignoring past experience and advice, and believing passion will fill in the gaps. Failing at execution again, and again, and again.
I’m happy to work with a team that is good at avoiding these traps. A team that knows that you don’t start big — you start small, whenever you can. You start with proven technology, not whatever’s the new shiny thing (the $250k ‘super trommel’ in Season 3 is a brilliant example of the latter); you start by consulting with experts, not pulling them in when your project has already failed; but most importantly, you start by thinking about the problem, and trying to predict what will go wrong, and doing your best to prevent it. These are important things for any team anywhere to recognize, and I think is a key aspect of the difference between success and failure for many teams.
Stay close to what you know. Feel free to take risks, but do them knowing they are risks, and don’t treat them as a sure thing. And above all else: Think.