Shipposting

Expectations

I’m a software engineer, so of course, this isn’t the blog I wanted to build. I have begun building it several times, and this isn’t what I envisioned, but it exists. The fact that you’re reading these words at all is evidence that I wrote a blog. I expected to build a place to express my ideas in long-form, so I started building a blog that could accommodate those ideas. But, those expectations are different, “building a blog” and “writing a blog.” The reason you’re able to read this at all is that I stopped building it and wrote it instead. It’s finally here, and I am conflicted about it. I’m dissatisfied with it and shipping it regardless.

For me, dissatisfaction is challenging to accept when shipping a product. In Reid Hoffman’s words:

If you are not embarrassed by the first version of your product, you’ve launched too late.

Hoffman’s wisdom about perfectionism has always felt like it wants me to ignore my emotions. Accepting it without reasoning is problematic because it feels like accepting any other positive mindset grift — like the only thing between you and a billion dollars is waking up at 4 am or an ice bath daily. Overlooking your embarrassment might get you to the goal, but ignoring it fails to learn anything from it. Without learning from it, you’ll constantly battle anxiety, and you may be unable to reassure yourself that the goal is worthwhile.

Goals

It’s crucial to describe goals with precision. Without that precision, it’s easy to conflate two distinct ideas. Until now, that’s been my problem. More precisely, I’ve been trying to “build a blog platform” rather than “write and publish more.”

It’s second nature for engineers to consider one side of your requirements primarily — they care about the product you build. Holding the product to strict quality standards over everything else is a convincing trap. The reality is the existential need for the product is its audience (aka customer, reader, user, etc.) If a product doesn’t reach its audience, engineering has failed to build it. It fails despite the features and quality it fails with. It’s disheartening that engineers can’t save a product with quality or expertise alone, but the silver lining is that shipping is straightforward despite its emotional difficulty.

The distinction between goals is in the shipping process; it lies in the “what,” “how,” and “to whom.” In the past, I would object that shipping a platform is shipping. But, the audience is an existential need, and building a platform is shipping a product to an audience of just me. Writing blog posts is shipping a product to my actual audience — readers.

Creating for yourself is comfortable because you’re both the audience and the engineer. It short-circuits shipping without the vulnerability. Still, it’s important not to conflate this goal that looks like yours with your actual goal. It’s essential to Keep the actual product and audience in mind. It helps to set clear objectives to prevent yourself from misconstruing non-goals. Clarity here prevents amplifying your goal into something immense and more intricate.

Reality

Many engineers will see the “why” behind ignoring aspects of technical product building. It’s the same as “feature creep” or “scope creep” in project management. The reality is that nobody can be everywhere at once. Nobody can build everything all at once. Because of that, not all features can be the top priority. Non-technical goals are still features to develop. Shipping early might mean delaying almost all technical features. That can feel disappointing, but it’s not that engineering does not matter — it matters a lot. Engineering can be instrumental in early decisions and keeping future features in mind. It ensures the product doesn’t commit itself to a path needing dramatic correction. Engineers must ship with regularity to avoid blocking the primary goal.

Software engineering and architecting are roles surrounded by hairy realities. Those often manifest as legacy software, which can feel outdated or shortsighted. Legacy software and brownfield systems rarely provide teams with the freedoms they desire. Part of the job is working within those constraints (and complaining at a sensible volume). Engineers fantasize about greenfield projects where they can build from scratch. The reality is that a brownfield system still exists because it provides value. It has already met its existential goal of reaching an audience despite the choices made and the pain it causes engineering today.

Reality doesn’t demand engineers give up their craft and build unsound software. It instead asks that you not see greenfield systems as a blank slate but as an arena. Reality constrains that arena and requires deliberate engineering. Rather than building everything, you should stake these projects in their existential goal. They should reach their audience first. Engineering goals can still be vital cornerstones, but building small and shipping to users is essential.

Shipping

Shipping can feel uncomfortable, vulnerable, and embarrassing. You must expose your product to your audience, and your expectations may still be out of reach. The product may look terrible or only work under some conditions.

But it’s critical to remember it didn’t exist before shipping. Before shipping, it was an elaborate idea and some exploration. Now, the product exists.

Shipping isn’t as embarrassing as most people expect.

I used to speak at conferences early in my career, and since, that has tapered off. I could claim that changing jobs, COVID-19, moving, or getting married contributed, but that’s not true. I stopped because my professional experience developed, and the standard I set for “what is conference worthy” went up. I have gatekept myself from speaking further in an unfair way. A byproduct of this post is renewing my commitment to speaking and writing in public.

Developing taste and becoming an expert means establishing your critical thinking. It’s often convenient along the way to become your own greatest critic. Yet, self-doubt isn’t a form of humility; it’s a form of anxiety. Remember, when you’re shipping a product, the default is that nobody notices or cares. At worst, an ineffective launch might yield mean comments from people you’ve never met. Ground your anxiety and remember that this isn’t the same as public shaming. People and companies from whom your audience expects more are still creating bad products. It’s alright to land among them temporarily if you intend to persevere.

Being vulnerable is good.

Your taste and expertise weren’t formed in a vacuum or granted from the ether. You assembled them from the learnings and experiences of others. Insulating your projects and self-criticizing them may yield something inherently “yours,” but your own ability will always limit your projects. Being vulnerable and shipping means questioning and validating your ability with your audience.

An engineer develops their intuition and expertise in their career through learning. Early in your career, there is no foundation, so you have to learn everything, but later, you can use experience to survive. But experience is an assumption that the way you have learned something is complete and correct. It’s an assumption that your anecdotes and rules are a comprehensive view. Allowing yourself to be vulnerable is sound engineering because you open yourself to challenge, prove, or debunk your assumptions. Doing this will enable you to grow your understanding and continue learning with more expertise. It allows you to challenge your early beliefs about what makes a good product, how to build it, and what is suitable. Not doing this leads to stagnating and relying on your early career assumptions being enough to get by.

Embrace discomfort.

Being uncomfortable isn’t always bad. We’re used to it signaling that it’s time to do something new or change, but discomfort can also be a symptom of growth at work. It suggests you’re challenging your existing assumptions, stretching your ability, and developing.

As an engineer, I understand discomfort through dissatisfaction the best because it’s why I build. I set out to fix it or build something new if something isn’t good enough. I am satisfied by fixing the thing that I saw as unsuitable. The discomfort that comes from early shipping is different. It’s an anxiety that I will feel dissatisfied with myself or my creation. Ironically, I built that creation to fix dissatisfaction with something else.

Shipping is rewarding.

Shipping early and often helps amortize the pain and anxiety that comes from growth. But it also realizes the benefits of that same growth. You can continue with more robust capability by realizing your incorrect assumptions early. By realizing your greenfield product, you can accurately define its arena’s constraints. You can engineer a sound solution based on reality.

Many creators describe shipping as a dopamine hit or something that is in itself rewarding. I agree there’s something delightful about seeing efforts fruit rather than die on the vine. But I remember to learn from my feelings of anxiety. What I choose to learn is that growth is uncomfortable. My embarrassment is groundless. My product, budding, lacking functionality, and still not up to my expectations, exists.