每个人都告诉我要放弃。
并不是出于恶意——而是真诚的、经过深思熟虑的建议，那种人们对他们认为正在浪费时间的人才会给出的关切。"你现在是创始人了，Gautam。把代码工作委派出去吧。"我在 Seahawk Media 的联合创始人在 2018 年左右也说过类似的话，当时我们同时有超过一百个活跃客户项目。逻辑很清楚：创始人应该思考系统、招聘、销售管道。而不是提交代码。Seahawk Media said something similar around 2018 when we crossed a hundred active client projects simultaneously. The logic was sound: founders should think about systems, hiring, pipeline. Not pull requests.
我忽略了那个建议。而且我很高兴我这样做了。
---
我几乎放弃编码的那一刻（但我没有）
2019年，一个客户给了我一份简报，现在回想起来还是忍不住笑。一个中等规模的电商品牌——我不便透露名字——想要完整重建WooCommerce，定制产品配置器，应有尽有。期限很紧。我把这个项目分配给团队里的一个开发者，很有信心这正是我应该退一步的那种事。
三周后，开发者离职了。个人原因，完全可以理解。但我们只有半成品的配置器，客户在催我，代码库只有一个人真正理解。
那个周日上午7点，我打开VS Code，直到中午才关闭。我硬是搞定了。不是因为我是英雄——而是我其实还记得代码模式、WooCommerce的hook架构、woocommerce_before_add_to_cart_button在你用自定义文章类型来生成产品变体时的行为方式。我没有忘记。我只是在假装自己已经离开了。woocommerce_before_add_to_cart_button behaves when you've got a custom post type feeding product variations. I hadn't forgotten. I'd just been pretending I had moved on.
那个项目完全改变了我对自己角色的思考方式。
---
"写代码的创始人"到底是什么意思
不是说我在构建每一个功能。我没有。Seahawk有很多开发者在某些具体领域比我强——动画、复杂的React状态管理、大规模数据库优化。这不是假客套。这是事实。
但作为创始人写代码意味着我永远不会失去对工作的感觉。管理一个项目和理解一个项目是有区别的。当开发者告诉我"这需要两周"时，我能问出正确的问题——"这是两周因为API认证确实很复杂，还是因为我们在重新构建某个WordPress插件里已经存在的功能？"feel of the work. There's a difference between managing a project and understanding one. When a developer tells me "this will take two weeks," I can ask the right question — "is that two weeks because the API authentication is genuinely complex, or because we're rebuilding something that already exists in a WordPress plugin?"
你没法从高空俯视角问出那样的问题。就是没法。
估算问题
软件估算的问题在这里：它们既是开发者对自己讲的故事，也是对客户讲的故事。我见过一个资深开发者估算一个自定义 WordPress REST API 端点需要四天，但当我和他一起坐下来正确确定范围后，实际只花了六小时。不是因为他懒。而是因为我们都没有深入了解这个端点实际需要做什么。WordPress REST API endpoint that took six hours once I sat down with them and scoped it properly. Not because they were lazy. Because neither of us had dug into what the endpoint actually needed to do.
当你经常编码时，你对估算的BS探测器会大幅改进。
---
这让我成为一个更好的内部客户
没人告诉你运营代理机构的一件事：你的开发者是你的内部客户。你需要像说服外部客户一样说服他们接受好的决策。而一旦你停止用他们的语言说话，你就会失去这种能力。
我用 Figma 进行设计交付。我用 Git（具体是 GitHub，我们在 2021 年把所有东西从 Bitbucket 迁过去了）。我在 Linear 中写真正的工单，具体到开发者可以不用参加启动会就能开始工作的程度。仅最后这一点就为我们节省了可能每个项目 40 分钟的时间，而我们运行很多项目。Figma for design handoffs. I use Git (specifically GitHub, we moved everything there from Bitbucket in 2021). I write actual tickets in Linear with enough specificity that a developer can start work without a kickoff call. That last one alone has saved us probably 40 minutes per project, and we run a lot of projects.
如果你完全偏向"宏观图景"，这一切都不可能。你需要知道开发者在工单中需要什么。你只有坐在另一边才能知道这一点。
没人期望老板做的代码审查
我偶尔会留下 PR 评论。不是为了微观管理——我会明确表态。但一条评论比如"这个过滤器在每次页面加载时都会运行，我们能缓存结果吗？"传达了一些重要的信息：我正在关注重要的层面。
开发者尊重这一点。有些人对此感到惊讶。老实说，对此感到烦恼的人——那也告诉我一些有用的东西。annoyed by it — that tells me something useful too.
---
我在2024年实际使用的工具
作为一个科技创始人，我的技术栈无聊得令人尴尬。VS Code配上少数几个扩展（Prettier、GitLens、PHP Intelephense）。本地开发环境运行LocalWP——我在2020年从MAMP切换过来，从未回头。所有Git相关的操作都用Terminal，因为我从来没完全信任过任何GUI。LocalWP — I switched from MAMP in 2020 and never looked back. Terminal for everything Git-related because I never fully trusted any GUI.
在做客户项目时，我仍然选择WordPress。我们用Webflow、Shopify、定制Laravel都做过——但WordPress是我最快的，而速度在频繁跳进跳出而不是8小时专注工作时很重要。
上周二我用Coolors.co为一个客户的落地页快速修复而拉取品牌调色板。总共花了四分钟。如果去简报设计师、等待和审查的话要花一小时。这就是创始人自己编码优势的缩影。
---
停止编码时你真正失去的东西
大多数离开编辑器的创始人都说服自己会通过某种渗透作用保持技术能力。他们会从站会和Slack讨论中吸收知识。他们不会的。
这是实际发生的情况：
- 你的词汇会漂移。"API"、"webhook"、"缓存失效"——你开始使用这些词，但不知道它们在你特定技术栈中的具体含义。
- 你失去了原型设计的能力。两小时的编码会议能解答三场利益相关者会议都无法解决的产品问题。
- 你开始依赖开发者的可用性来做出小决策。曾经需要20分钟的事现在需要安排日程。
- 开发者会注意到。不是所有人都会说出来，但对于那些显然多年未接触实际工作的创始人，他们的互动方式会有一种微妙的转变。
我看过我尊敬的人经历这个过程。好人们建立了真正具有技术底蕴的代理机构，然后逐渐把自己抽象出了自己的专业领域。到了第五年，他们完全在经营业务，而且做得很好——但他们失去了某样他们说不出名字的东西。
---
反方观点（以及我为什么不同意）
反对创始人编码最有力的论点是机会成本。Paul Graham曾以各种形式写过这个问题——创始人应该做不可扩展的事情，但也应该关注焦点是早期运营的唯一真正优势。Paul Graham has written about this in various forms — the idea that founders should do things that don't scale, but also that focus is the only real advantage an early-stage operation has.
公平。完全公平。
但我认为这个论点更适用于风投支持的初创公司的产品创始人，而不是代理机构创始人和自由职业者。我们的背景不同。我们没有编码会分散注意力的融资跑道问题。我们有质量和信任问题——编码是我们解决这个问题的方式之一。
当Seahawk向企业客户推销复杂的WordPress迁移时，联合创始人能详细讨论数据库表结构和wp-config常量这一事实并非小事。这会改变会议的气氛。
---
我如何在不成为问题的前提下保护编码时间
我花了多年才想清楚这个问题。真的。我过去总是被动地编码——只有在什么东西坏了或开发者卡住了的时候才写代码。那是两个世界最坏的结合。你在代码中，但压力很大，永远进不了心流状态。
现在我这样做：
- 在周一和周四上午各预留90分钟。这两天上午9点30分之前不接电话。不可商议，自2022年以来一直在日历上。 No calls before 9:30am those days. Non-negotiable, in the calendar since 2022.
- 始终保持一个"创始人项目"在进行中。某个小东西——一个个人工具、一个客户的微功能、一个内部自动化脚本。现在是一个从Linear拉取我们项目状态并格式化为周摘要的Python脚本。180行，没什么花哨的。 Something small — a personal tool, a client micro-feature, an internal automation. Right now it's a Python script that pulls our project status from Linear and formats a weekly digest. 180 lines, nothing fancy.
- 每周至少审查一个PR。即使只是阅读。保持在diff中。 Even if it's just to read. Stay in the diff.
- 每季度从头重建一个东西。一个着陆页、一个插件、一个小集成。随便什么。重点是在基础知识上保持敏锐。 A landing page, a plugin, a small integration. Whatever. The point is staying sharp on fundamentals.
总时间每周可能就4到5个小时。就这样。没人建议你进行冲刺。
---
常见问题
写代码会让你成为更差的CEO或联合创始人吗?
只有当它挤占了实际的领导责任时才会。问题不在于写代码——而在于把写代码当作逃避创始人更难工作的策略：困难的对话、招聘决定、商业思考。如果在应该和流失客户沟通的时候打开了编辑器，那就是个问题。但每周四早上花4小时不是领导力失职。avoidance strategy for the harder founder work: difficult conversations, hiring decisions, commercial thinking. If you're opening the editor when you should be talking to a churning client, that's a problem. But 4 hours a week on a Thursday morning isn't leadership negligence.
如果我的团队看到我写代码，会不会觉得我不信任他们?
直话直说。我明确告诉过我的团队："我写代码不是在暗示你们错了或慢了。这是我保持对我们实际构建内容的理解的方式。"这个对话花不了90秒，通常只需要说一次。
这对运营更大团队的创始人来说现实吗?
说实话，在50人规模时比在15人时更难。但这个原则是可扩展的——即使具体做法会改变。到了一定规模，"写代码"可能意味着审查架构决策、每季度做一次探索性尝试，或深入理解Lighthouse性能报告里的内容，而不是自己写修复代码。关键是：别让技术能力完全退化。Lighthouse performance report rather than writing the fix yourself. The point is: don't let technical fluency atrophy entirely.
创始人什么时候应该真正远离代码?
当写代码阻碍别人成长的时候。如果一个开发者在等你审查他们的PR以合并他们的工作，而你总是瓶颈，那就是信号了。从关键路径上退出去。你还可以写代码——只是不在凌晨2点在主分支上。critical path. You can still write code — just not on the main branch at 2am.
---
编码让我保持诚实。这是我知道的最简单的说法。当你仍然能够阅读代码diff、估算功能、自己发布小东西时——你会看得更清楚自己的业务。你知道什么是真正困难的，什么只是解释得不好。这种清晰度比它每周花费的四小时要值得得多。
仍在打开编辑器。可能直到我在身体上做不到为止。