Backups and Giving Up
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:
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.
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.
Pictured: a bunch of servers that could be storing my backups for approximately $0.0002/month. But aren’t.
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.”
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.)