Grit your teeth and ship it

ID: 533d95f1
原文链接: https://seangoedecke.com/grit-your-teeth-and-ship-it/
作者: Sean Goedecke
日期: 2026-09-20
分类: auto
来源类型: article
标签: shipping, creative-work, engineering-culture, writing, ai-agents
质量评分: 3/5
抓取时间: 2026-09-20T23:30Z

中文摘要

Sean Goedecke 9 月 20 日短文：gifted programmer 和 gifted writer 共享同一个毛病——做不好的东西比不发出来更难受。他把 Ira Glass 那段"taste 先行,手艺跟不上"放在最前，自己接出两个分论。工程侧：系统越大越不可能"clean"，要求一致性有时候是把已知小错也复制过去最划算，gifted programmer 卡住不是因为不会做，是因为做完不肯交。写作侧：他承认每篇 blog 写完都觉得不行，但发多了回头看，"当时觉得好/烂"与"哪篇真的有人读"完全不相关，唯一可执行的策略是偏向输出而不是偏向打磨——他把这叫做 momentum-based，不是 outcome-based，同一个题目反复写三十遍不丢人。值得读是因为他把 shipping 这个被讲烂话题从"产品节奏"拽回"情绪管理"。

为什么值得关注

把 shipping 从"产品节奏"拽回"情绪管理"——gifted 卡住不是不会做，是做完不肯交，唯一可执行的是偏向输出。

English Abstract

Sean Goedecke's 2026-09-20 post argues that gifted programmers and gifted writers share one trait: preferring not to ship over shipping imperfect work. Anchoring on Ira Glass's "taste leads, craft catches up" line, he splits the lesson in two. On engineering: as systems grow they become impossible to keep "clean"; demanding consistency sometimes means reproducing known small flaws because that is the cheapest path, and gifted programmers get stuck not from inability but from unwillingness to release. On writing: he concedes every post feels bad on publication, but looking back the correlation between self-judgment and actual readership is near zero — the only viable policy biases toward output rather than polish; he calls it momentum-based, not outcome-based, and writes that revisiting the same topic thirty times is not embarrassing. The piece reframes the over-discussed shipping topic from product cadence to emotional management.

Obsidian 证据摘要

来源: OpenClaw定时任务/AK-RSS-Digest（89源精选）/2026-09-20-AK-RSS-Digest（89源精选）.md

原文摘录

# Grit your teeth and ship it
> 原文链接: https://seangoedecke.com/grit-your-teeth-and-ship-it/

---

Being good at building and being good at shipping are two separate skills. In the short term, they’re actually countervailing: if you have a gift for building, you’re likely to be _worse_ at shipping. Ira Glass has a classic quote about this.

> All of us who do creative work, we get into it because we have good taste. But there is this gap. For the first couple years you make stuff, it’s just not that good. It’s trying to be good, it has potential, but it’s not. But your taste, the thing that got you into the game, is still killer. And your taste is why your work disappoints you.

The only way around this is to **grit your teeth and ship it**. You have to force yourself to publish things you’ve made even when you think they’re crap.

### Programming[](#programming)

Gifted programmers have a [nearly pathological](https://www.seangoedecke.com/addicted-to-being-useful/) desire to build elegant, correct, neat systems. That’s what motivates them to learn the arcane details of their languages, or to spend time polishing and refactoring over and over again. But it’s also what makes them reluctant to ship. Any flaws in the software bother them on an emotional level. If they ship with those flaws, they feel like people will think they weren’t paying enough attention to notice them, or that they weren’t good enough to fix them.

This is annoying when you’re writing software on your own, but it’s completely fatal when you’re working in a tech company. Any large software system is covered in flaws, whether due to time pressure, [relative inexperience](https://www.seangoedecke.com/bad-code-at-big-companies/), [wicked features](https://www.seangoedecke.com/wicked-features/), or a hundred other reasons. Working with it is a process of compromise: of finding the best possible solution given the quirks and foibles of the codebase. In fact, since the most important thing in large codebases is [consistency](https://www.seangoedecke.com/large-established-codebases/), the right thing to do is sometimes to _duplicate_ flaws, assuming they’re not catastrophic.

Gifted programmers often freeze up. I’ve often seen them retreat to smaller domains where they can safely make the code “correct”: tweaking dev-environment setup, or refactoring tests. Sometimes they just do nothing, and spin in shame and guilt (plus the compounding shame of not achieving anything) until they implode and quit. If they had worse taste, they wouldn’t be as good at programming, but they’d be a lot more useful. You can typically improve a bad diff with time and effort. You can’t improve _no_ diff.

### Writing[](#writing)

I have a sensitive eye for awkward sentences and uneven prose. That can make writing an unpleasant process: I know what I’m trying to say, but I can’t seem to say it in a way that’s as clear and as elegant as I know is possible. More than half the time I finish drafting a blog post, I look at the post and don’t think it’s very good. But I (mostly) grit my teeth and publish it anyway, because **you have to bias towards shipping**.

Like any skill, shipping gets easier the more you practice it. If I don’t publish a blog post for a month, I always feel like the next draft is too poorly-written or uninteresting to put out there. But when I’m publishing a post per day, I typically feel great about each draft. When I go back and read my old posts, I can’t tell which ones I felt good about and which ones I felt bad about. There’s no correlation between that and the posts that become [popular](https://www.seangoedecke.com/popular/). Here are some posts I didn’t like as I was writing them but that resonated with my audience:

-   [Do the simplest thing that could possibly work](https://www.seangoedecke.com/the-simplest-thing-that-could-possibly-work/)
-   [Software engineering may no longer be a lifetime career](https://www.seangoedecke.com/software-engineering-may-no-longer-be-a-lifetime-career/)
-   [Software engineers should be a little bit cynical](https://www.seangoedecke.com/a-little-bit-cynical/)

Here are some posts I thought were pretty good but that didn’t find popularity:

-   [Weak engineering managers](https://www.seangoedecke.com/weak-managers/)
-   [Paths through the space of all possible solutions](https://www.seangoedecke.com/solution-space/)
-   [Trying to impress people you don’t respect](https://www.seangoedecke.com/impressing-people/)

You just can’t predict what people will find interesting or useful. Producing a high volume of work thus gives much better yield than a small amount of highly-polished work.

It can be disheartening to realize that some of your most casual, throwaway work will be more successful than the work you slaved over[1](#fn-1). Specifically, it’s disheartening because it means realizing you don’t have _control_ over your own success. You can’t produce something successful by focusing on a single piece until you’re satisfied it’s great. Instead, you just have to do a lot of things and see what sticks. You have to be [momentum-based](https://sunilpai.dev/posts/the-senior-engineer-death-spiral/), not outcome-based. In other words, **you have to grit your teeth and ship it**.

One common reason to write less is getting overly precious about your ideas. If you think you’ve got a really compelling concept, you don’t want to “waste it” on a poorly-written story. But in fact you can just write about the same thing over and over until you get it right! I have written like thirty blog posts about shipping (this is one of them), or about how tech companies work, or about how internal emotional regulation is as important as technical ability. I expect to continue writing and thinking about these ideas for as long as I find them interesting.

* * *

1.  Anthony Burgess famously [claimed](https://en.wikipedia.org/wiki/A_Clockwork_Orange_\(novel\)#Writer's_appraisal) to have “knocked off” _A Clockwork Or