Why We Ship

Originally written at during High Seas, our second “Universal You-Ship-We-Ship” program which ran during the winter of 2024/2025. This is the last of three essays intended to introduce newcomers to some of the philosophical underpinnings of Hack Club.

Why We Ship

In my last essay we talked about the hacker mindset, its role in how Hack Club works, and how you can be a part of this mission (should you choose to accept it). We covered how the twin engines of experimentation and iteration drive us toward our goals. And just like twin engines on a boat, both of these processes have cycles built around a singular moment of combustion: the ship.

“Shipping” means deploying a project in a form that provides an actual, real-world validation of whether your project can accomplish its goals. For a stair-climbing robot, this would mean assembling your prototype, powering it on, and actually trying to climb some stairs. For a video game, you might put a demo online, send it to some people, and ask them if it’s actually any fun. It’s always a nice moment to see stairs get climbed or players have fun, but that’s not the most important reason why you should ship. We ship to convert conjecture into truth. Remember that as hackers we don’t trust our theoretical models; the true value of shipping comes when a belt snaps and your creation tumbles down the stairs, revealing precisely what you were wrong about this time. With any luck, when you ship the next iteration you’ll get to be wrong about something entirely new.

Shipping is a habit you must cultivate to keep yourself honest; with others, but principally honest with yourself. Every once in a while I find myself watching something I built experience a serious failure, something beyond the minor well-controlled failures we actively seek out as part of the constructive process. Perhaps a product launches and flops, or a prototype breaks in a way that destroys something expensive. Almost all of these moments could be described as a failure to imagine the particular way in which something will ultimately break. But most of the time, a review of my decisions turns up some obvious way that a basic reality check would have made a lesson learned the hard way a whole lot easier. The greater failure there is not that I didn’t see how something would break, but rather that I convinced myself that I knew it would work.

It turns out that the universe is very complicated, and my capacity to model it is usually far outstripped by its capacity to surprise me—sometimes in rather embarrassing ways. As Uncle Iroh said in The Last Airbender, “Pride is not the opposite of shame, but its source. True humility is the only antidote to shame.” When I make something that seems to be working, or even that I just expect to work, I often feel quite proud… but if I allow that pride to seduce me, it has a way of turning into shame when my grand visionary project turns out to be kind of a dud (and wow, this has happened a lot in my life). Humility means testing our assumptions, and the best way to continuously test our assumptions end-to-end is to ship fast and ship frequently. There are many more ways for a system to break than to work; when you ship fast and frequently, you increase the odds of failing successfully, i.e. when change is merely painful instead of impossible.

This is the primary reason why you are required to ship projects for High Seas to receive doubloons! During Arcade, it didn’t matter what you built or whether it even ultimately worked (let alone was actually any good). And while a lot of people built some really cool projects, a large percentage of the tickets other people earned came from code that went absolutely nowhere. Even among the finished working projects, a lot of them were what we’ve come to call “slop”: products that nobody wants, not even the people who made them. Bland checklist apps, portfolio websites that were lazily copy-pasted from templates, dozens of identical tic-tac-toe and 2048 games… nobody is excited about those projects. Nonetheless, a lot of people made them anyway because that’s what our system incentivized. This is one of the biggest ways we got to see our experiment fail, but it was a successful failure because after a long summer of iteration on Arcade we could turn around and incorporate our findings in the next experiment, High Seas! So this time around, we did our best to align the optimal strategy for stacking up doubloons with the experimentation and iteration model laid out in the previous essay. Let’s take a look at what that optimal strategy is; consider this free advice on how to get more doubloons from High Seas, and hopefully whatever comes next.

Your best first move is to try a bunch of small experiments. Ship a quick MVP for each of them to see which concepts people are excited about. Sooner or later you’ll hit something that resonates with your peers, and you’ll see that reflected in the size of your payout. This is when you’re ready to move from experimentation to iteration, and that means shipping updates instead of whole new projects. Work on new features in bite-sized chunks that people can easily understand, and ship them as updates to your project. As you stack more hours onto your project, each of those updates will get a new rating that will probably be in a similar range as your original MVP, maybe even higher… at least, for as long as you are squeezing real juice out of your updates. As your project gains more hours, it will be compared against other projects with more hours, so eventually you will probably run low on ways to meaningfully improve it and its performance will start to dip relative to the competition; after all, you can squeeze a lot of juice out of a really cool portfolio site but diminishing returns will probably come faster than something like a custom game engine, even if the portfolio beats the engine at first. This is when you may want to try some fresh experiments, informed by all your new knowledge, which starts the whole process over again.

This is the optimal strategy for High Seas… or at least, that’s my hypothesis based on how we designed it. We designed it this way to approximate the optimal strategy for building things in the real world. But of course, I can’t say for sure how this experiment will work. High Seas is our latest ship, and we’re relying on you to show us all the ways it will fail. You’ve already shown us quite a few, and each of those failures is a discovery of a fresh opportunity for improvement. Your experiments feed our iteration, so that our experiment can feed yours, so that step by step we may all march asymptotically together toward truth.

A final note: I had most of this essay written in late-August 2024. I finished it mid-December. And yet, I haven’t shipped it. I haven’t shipped because I didn’t think it was inspiring enough; the last two essays in this series had a sort of punch to them that tied their thesis back to the world at large, and I just wasn’t feeling it in the same way with this one. But by leaving it on the shelf, I am missing the point of the essay itself. So… here it is. Essay number three. It’s not perfect, but it’s shipped. Better late than never!