I had a pretty solid post lined up for today, but it’s going to have to wait. Instead, let’s talk about the importance of:

  1. Backups, and
  2. Bouncing back

First, backups: back up your files! This is one of those things you can “know” but subsequently “learn.” Here’s what happened in my case: I have two laptops; an ancient Thinkpad and a really zippy Dell. The Dell runs a modern version of Windows, which means it can handle all manner of distracting programs and websites. The Thinkpad runs Arch Linux, so no games, and it’s so old basically any Javascript-heavy website is unusable; scroll down a couple pages on Twitter, and it will slow to a crawl and then crash.

This has made the Arch laptop an amazing productivity tool. When I’m using it, there’s literally nothing better to do than work, so I get a lot of work done. But this happened by accident, and over time, so I never got around to treating it like a serious computing device; it was my disposable backup computer, for disposable backup work.[1]

And now it doesn’t boot. It’s broken enough that when I turn it on, it sends me to a “recovery terminal,” but doesn’t even accept text input. Whoops.[2]

Most of the files on that machine are, in fact, worthless; either I’ve already uploaded them somewhere or I never will. Annoyingly, though, there are a few half-finished drafts of really big projects, including one that’s probably my most involved programming project ever: an agent-based model of cyclical industries. I’m at a couple hundred lines of Python and a couple thousand words of writeup, and still going strong, and it would be pretty annoying to lose that.

On the other hand: it wouldn’t be that bad, actually. Sure, that’s tens of hours of wasted time. On the other hand, I’m sure I’ve wasted tens of hours this year in other ways, and at least this way I learned something; if I decided to rewrite the model from scratch, I’d avoid a lot of mistakes and probably have cleaner code. After all, what’s the point of an exercise like writing that model in the first place: it’s to get better at doing similar tasks. And there’s nothing so similar as the same thing all over again.

There’s a tendency for big side projects to die this way: the proximate cause is always some temporary inconvenience, from which the project never recovers. “I forgot to renew my domain — so I stopped writing the blog.” “When I moved, I lost the book I was using — so I didn’t ever end up learning Haskell.” “While I was doing my research, they announced a new product was doing well and the stock went up 20% in two days — so I never got around to investing.”[3]

And yet if you asked someone at the outset if what they were doing was worth the effort, I don’t think their margin of error would be tight enough that that would make a difference. Most people start side projects assuming the return will be massive compared to the effort, since that’s the only way to justify effort in the face of uncertain rewards.

The real issue is not that minor inconveniences thwart us; it’s that we’re bad at cutting losses when something isn’t working out. The catalyst is just a catalyst; it’s not the event itself. Investing lore provides a good solution to this: many investing styles suggest cutting losses and letting winners run. I used to reject this, since from the standpoint of a single asset it doesn’t make sense: at best, the new price is as efficient as the old price was; at worst, you’re just getting out of stuff when it’s cheap.

But it makes more sense from the perspective of the investor. Your winners are the situations you understood well; your losers are the situations you misunderstood. And nobody likes to admit that they were wrong; people would much rather be early, or too smart for the market, or whatever. The persistence of loss-cutting a a discipline implies that the adverse selection from being involved in more expensive assets is more than compensated for by the positive effect of being involved in situations you understand well.

Some investors take this discipline a step further: not only do they sell whatever’s moving against them; they also sell whatever hasn’t moved in their favor yet. The basic argument is the same, just with a higher bar: if you really knew what was going on, you wouldn’t have bought until it was time to buy; now you have to revisit your thesis. As it turns out, success across several fields is related to being realistic about your own mental limitations — knowing when to double down and when to give up.

(And when to back up your files, naturally.)

Don’t miss the next story. Sign up for my occasional email newsletter. Or check the About/FAQ page for more.

[1] There must be some kind of metaphor here — Slack, Yammer, and Twitter all started as minor side projects, too. And at least in Twitter’s case, their infrastructure decisions were about as well thought-out as mine.

[2] I’m pretty sure I know how to fix it, but there’s still a chance I’ve lost everything.

[3] This is a true story about why I didn’t buy any Apple at a split-adjusted $1.25/share in May of 2003. I wasn’t prescient or anything: it was just another value stock back then.

I write about technology (more logos than techne) and economics. Newsletter: https://diff.substack.com/

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store