Grit your teeth and ship it
Short summary
Building something well and shipping it are opposite skills—perfectionism that makes you a good craftsperson makes you reluctant to release work. The only way forward is forcing yourself to publish despite thinking it's flawed, because volume and iteration beat polished isolation.
- Gifted programmers and writers often sabotage themselves by refusing to ship work that doesn't meet their standards, but imperfect shipped code beats perfect unshipped code every time.
- You can't predict what people will find valuable, so producing high volume of work yields better results than agonizing over individual pieces—your throwaway posts often outperform what you labored over.
- Shipping is a learnable skill that gets easier with practice; the more frequently you publish, the less perfectionism paralyzes you, and you stop being able to distinguish between work you felt good about and work that actually resonated.
Full summary
Building something well and shipping it are fundamentally different skills that often work against each other. People with good taste—the kind that drives them to learn deeply and refine their work—tend to be paralyzed by perfectionism. Ira Glass nails the core problem: your taste is what got you into creative work, but it's also what makes you hate your early output. The gap between what you can recognize as good and what you can actually produce is real, especially in the first couple years. The only way past it is to force yourself to publish work you think is mediocre.
In programming, this tension is particularly destructive. Talented developers have an almost compulsive need for elegant, correct systems—that's what makes them good at the craft. But it also makes them reluctant to ship code with any flaws. In a real tech company, though, every large system is covered in compromises and quirks. The right move is often to duplicate existing flaws for consistency rather than chase perfection. When gifted programmers freeze up, they retreat to safer domains like tweaking dev environments or refactoring tests, spinning in shame until they quit. A mediocre diff that actually ships beats a perfect diff that never gets written.
The author's experience writing confirms this pattern. He can't predict which posts will resonate—some pieces he agonized over flopped while casual throwaway work became popular. Publishing frequently destroys the false sense of control you get from polishing one piece endlessly. Instead, you have to be momentum-based: produce volume and see what sticks. The real trap is treating ideas as too precious to "waste" on imperfect execution, but you can write about the same concept thirty times until you nail it. Shipping is a skill that gets easier with practice, and the only way to get better at it is to grit your teeth and do it.