每个人都告诉我要放弃。
不是残忍地，而是真诚地、深思熟虑地，带着人们对认为某人在浪费时间的人才会有的那种关切。"你现在是创始人了，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钩子架构、当你有自定义文章类型馈送产品变体时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.
如果你完全偏向"宏观图景"，这一切都不可能。你需要知道开发者在工单中需要什么。你只有坐在另一边才能知道这一点。
没人期望老板做的代码审查
有时我会发表一条拉取请求的评论。不是为了微管理，我会明确说明这一点。但一条诸如"这个过滤器在每个页面加载上运行，我们能缓存结果吗？"的备注传达了一些重要的东西：我在重要的层面上关注。
开发者尊重这一点。有些人对此感到惊讶。坦白说，被它惹恼的那些人，那也告诉我一些有用的东西。annoyed by it, that tells me something useful too.
---
我在2024年实际使用的工具
我的技术栈对于一个科技创始人来说糟糕到令人尴尬的程度。VS Code加上一些扩展（Prettier、GitLens、PHP Intelephense）。一个运行LocalWP的本地开发环境，我在2020年从MAMP切换过来，再也没有回头。用终端处理所有Git相关的事情，因为我从未完全相信任何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.
公平。完全公平。
但我认为这个论证对 VC 支持的初创产品创始人比对代理创始人和自由职业者更适用。我们的背景不同。我们没有编码会分散注意力的融资问题。我们有质量和信任问题，编码是我们解决它的一部分。
当Seahawk向企业客户推销复杂的WordPress迁移时，联合创始人能详细讨论数据库表结构和wp-config常量这一事实并非小事。这会改变会议的气氛。
---
我如何在不成为问题的前提下保护编码时间
我花了好几年才想明白这个。真的。我过去反应式编码，只有在东西坏了或开发人员卡住了才会编码。那是两个世界中最糟的。你在代码里但很紧张，永远进不了心流状态。
现在我这样做：
- 在周一和周四上午各预留90分钟。这两天上午9点30分之前不接电话。不可商议，自2022年以来一直在日历上。 No calls before 9:30am those days. Non-negotiable, in the calendar since 2022.
- 始终保持运行一个"创始人项目"。小东西，个人工具，客户微功能，内部自动化。现在我在做的是一个 Python 脚本，从 Linear 拉取我们的项目状态并格式化成周报。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.
---
写代码让我保持诚实。这是我能想到的最简单的说法。当你仍然能读懂代码差异、估算功能工作量，并自己发布一个小功能时，你会更清楚地看待自己的业务。你知道什么是真正困难的，什么只是解释得不好。这种清晰的认知比它每周花费的四个小时要值得多。
仍在打开编辑器。可能直到我在身体上做不到为止。