Year of shipping

In 2025, I would like to be a bit more disciplined about “shipping”: about actually putting things into the world.

This is not (though I know it might seem it) in contrast to my distinction between working effectively and productivity. Rather, it is a recognition that I have been ineffective in a certain way: by not committing to “shipping” I have not been forcing myself to make hard choices about priorities. It is one thing to say I would like to do some project or other, to make some open source contribution, to learn something. It is something else to make that concrete by choosing which of those to commit to making real, and which to set aside in favor of the ones I commit to.

So, thematically, I am aiming for 2025 to be a year of shipping.

Chris Krycho, A Year of Shipping

Shipping commitments:

Stuff I have shipped so far:

Sprint to Demos

My goal with the early sub-projects isn’t to build a finished sub-component, it is to build a good enough sub-component so I can move on to the next thing on the path to a demo. ✨

This tradeoff isn’t just manifested in functionality. It may be manifested in algorithmic or design considerations. For example, you may know that in the future, you’ll need to use something like a real database or a fancy data structure or support streaming data. But for the initial set of work, you can just use in-memory contents, built-in data structures such as dictionaries, and require all your inputs/outputs up front.

I think this is an important tradeoff so I will repeat it: do not let perfection be an enemy of progress. Going further, do not let future improvements you know you’ll have to make stop you from moving on to the next thing. The goal is to get to a demo.

Mitchell Hashimoto, My Approach to Building Large Technical Projects

Focus