《奔跑吧，程序员》全书导读：从零开始打造产品、技术和团队

Mon, 24 Feb 2020 21:00:00 +0800

《奔跑吧，程序员》全书导读：从零开始打造产品、技术和团队

参考书籍：Yevgeniy Brikman《奔跑吧，程序员：从零开始打造产品、技术和团队》（Hello, Startup，O’Reilly 2016，人民邮电出版社 2018 年中文版，吴晓嘉译）。目标读者：没读过这本书、想快速了解它讲了什么、值不值得读的程序员和创业者。阅读目标：用一篇文章把全书三大部分、12 章的核心内容讲清楚，配结构图和真实案例。

这本书是什么

作者 Yevgeniy “Jim” Brikman 是 LinkedIn 的早期工程师，后来参与创立 Gruntwork。他把这本书定位为**“给创业者的 Hello, World 教程”**——就像学一门编程语言时先写一个 printf("Hello, World") 让程序跑起来一样，这本书教你怎么让一家创业公司的三个核心部件跑起来：产品、技术、团队。

作者在序言里讲了一个自己的糗事，很能说明这本书的价值：他在 TripAdvisor 的第一个项目是给酒店列表页加一个新选项，上线后页面加载变得奇慢无比——因为他的代码在排序时每次比较都要调两次数据库，对近 2000 家巴黎酒店排序，一次页面加载就触发近 4 万次数据库调用，差点把数据库服务器累趴下。学校教了他算法和编程，却没教他"代码跑在真实世界里会发生什么"。这本书就是要补上这一课。

全书的骨架非常清晰：

flowchart TD
    A["奔跑吧，程序员<br/>Hello, Startup"] --> P1["第一部分：产品"]
    A --> P2["第二部分：技术"]
    A --> P3["第三部分：团队"]
    P1 --> C1["第1章 为何创业"]
    P1 --> C2["第2章 创业点子"]
    P1 --> C3["第3章 产品设计"]
    P1 --> C4["第4章 数据与营销"]
    P2 --> C5["第5章 技术栈的选择"]
    P2 --> C6["第6章 整洁的代码"]
    P2 --> C7["第7章 可扩展性"]
    P2 --> C8["第8章 软件交付"]
    P3 --> C9["第9章 创业文化"]
    P3 --> C10["第10章 求职之路"]
    P3 --> C11["第11章 招兵买马"]
    P3 --> C12["第12章 学习"]

下面按三大部分逐一展开。

第一部分：产品

第 1 章为何创业

作者先给"科技创业公司"下了个定义，综合了三位大牛的观点（Eric Ries、Paul Graham、Steve Blank），提炼出四要素：

flowchart LR
    S["科技创业公司"] --> A["产品是技术"]
    S --> B["环境极度不确定"]
    S --> C["目标是大幅增长"]
    S --> D["运作模式是探索"]

注意：和公司成立时间、员工数、估值都无关。一家 500 人的公司如果还在探索可复制的商业模式，它仍然是创业公司；一个三人团队如果做的是成熟外包生意，就不是。

为什么要去创业公司？作者给的理由是更多的机会、更多的所有权、更多的乐趣。但紧接着用很大篇幅泼冷水：

创业并不光鲜：媒体塑造的"顿悟后一夜成功"是幻觉。Marc Andreessen 说创业时"你只能体会到两种情绪：狂喜和恐惧，而且睡眠缺乏会放大这两种情绪"。
创业是牺牲：Stylefeeder 创始人 Philip Jacob 26 岁时连续八九个月每周工作 90 小时，体检时数值"像 60 岁的人"。
你大概率不会变富：作者分析了 60 多万家创业公司，回报遵循幂律分布——仅 34 家（Facebook、Twitter、Uber 等）就占了总市值的 76%，约 75% 的风投支持创业公司以失败告终。

一个很反直觉的例子：Facebook 联合创始人 Dustin Moskovitz 说过，Facebook 的第 100 号员工赚的钱，比硅谷 99% 的创业者还多。所以对多数人而言，“加入一家高速成长的创业公司"比"自己创业"是更优的赌注——同样的十年，员工可以换 3-4 家公司分散下注，而创始人从创立到退出平均要熬 7-8 年（Facebook 8 年、LinkedIn 8 年、Zappos 10 年）。

经验法则：只有你愿意把生命的下一个十年都花在这家公司上，才去创业。

第 2 章创业点子

本章先拆穿了一个迷思：点子不是顿悟。阿基米德喊着"尤里卡"跳出浴缸的故事出自 200 年后别人的记述，很可能是虚构；牛顿没有被苹果砸中，万有引力他研究了 20 年；爱迪生也没有"发明"灯泡——灯泡已经存在 70 多年了，他只是试验了 6000 多种灯丝材料。

点子的真实产生过程是重新合成，一切创造都是三步：

flowchart LR
    A["模仿"] --> B["转换"] --> C["合并"]
    C -.->|"案例：Google 之前至少有 10 个搜索引擎，<br/>PageRank 思想源自 60 年代的文献计量学"| D["新点子"]

所以"我有一个绝妙的点子但怕人偷走"的秘密模式完全没必要——真正吸引竞争者的不是点子本身，而是点子受到广泛关注。事实上多数行业根本没有先发优势：1993 年的研究显示，近半数的市场先行者最终失败了。

点子从哪来？作者给了七个培养创造力的方法，其中最实用的是记录点子日记（达·芬奇、爱迪生、维珍创始人布兰森都有这个习惯）——MIT 和 CMU 的研究表明，提高点子的数量比提高平均质量更能带来好点子，“想要好点子的关键是有很多坏点子”。

有了点子之后必须验证。CB Insights 分析 100 多家失败创业公司，头号死因是"没有市场需求”。Steve Blank 的"客户开发"方法论是核心：

flowchart LR
    A["验证问题"] --> B["验证 MVP"] --> C["验证产品"]
    B -.->|"不通过就退回"| A
    C -.->|"不通过就退回"| B

验证问题时要跟至少 10 个真实客户交谈——“如果你找不到前十个会购买的用户，这个点子就是在哄人”。

书中的反面案例很生动：Jeff Novich 做了 Patient Communicator（帮医生管理病人的系统），打了数百个推销电话、发了上万封邮件、还上了福克斯新闻，最后只得到一位付费医生（后来也停业了）。事后他才明白：“医生想要的是更多病人，而不是更有效率的诊所。"——他解决的是一个根本不痛的痛点。

这一章还有个著名的对照：1999 年 Webvan 烧掉 8 亿多美元做生鲜配送后破产；十几年后 Instacart 做同样的事却成功了。差别就是红杉资本爱问的那句**“为什么是现在？”**——智能手机、GPS、移动支付、用户习惯，这些"万事俱备"到 2012 年后才凑齐。

第 3 章产品设计

程序员最容易忽视的一章，也是本书最出彩的部分之一。核心立场是 Jeff Raskin 那句话：“界面即产品”——用户眼里的 Google 就是一个文本框加一个结果页。Joel Spolsky 称之为"冰山的秘密”：UI 只占全部工作的 10%，但界面糟糕，人们就会认为你的一切都糟糕。书里有 7 名程序员在 LinkedIn 会议室被一个问题跟踪软件难住几小时、最后改用便利贴的真实故事。

设计的首要障碍是知识之祸（Curse of Knowledge）。斯坦福 1990 年的经典实验：让"敲打者"敲出歌曲节奏给"倾听者"猜，敲打者预估对方能猜中 50%，实际 120 首歌只猜中 3 首（2.5%）。程序员设计软件时脑中"听着完整的歌曲"，用户听到的只是摩尔斯码。所以 Steve Krug 才说：“没人想读说明书。”

设计原则里最值得记住的几条：

目标不等于任务：NASA 花数百万美元造太空笔而苏联宇航员用铅笔（传闻），说明盯任务会跑偏；“任务随技术变化，目标很稳定”。
别为"平均用户"设计：Alan Cooper 说"想让 50% 的人 50% 满意是行不通的，要让 10% 的人 100% 心醉神迷"。
产品要有礼貌：Gmail 检测到你写了"附件"却没贴文件会弹确认框；发送后留几秒可以"撤销"。这就是考虑周到的设计。
简单来自削减：雕塑家不是往石头上加东西，而是去掉多余的部分——“达到完美并不是没有东西可以添加，而是没有东西可以去除”。

下半章讲 MVP（最小可行产品）。Eric Ries 的定义是：以最小的付出最大化地验证性地了解客户。MVP 不是一次性行为，而是一个循环：

flowchart LR
    A["找出风险最大的假设"] --> B["表述为可测试的假设"]
    B --> C["构建最小实验 MVP"]
    C --> D["分析结果"]
    D -.->|"循环"| A

书中归纳了五种 MVP 类型，每种都有一个经典案例：

MVP 类型	代表案例	做法
展示页面	Buffer	只有一个介绍页+价格页，用价格按钮的点击量验证付费意愿
介绍视频	Dropbox	4 分钟演示视频放 Hacker News，24 小时内 7 万人注册等候
众筹	Pebble	只拿一个原型上 Kickstarter，从 6.8 万赞助人处筹到 1000 万美元
绿野仙踪	Zappos	前台接单，后台"人肉"去鞋店买鞋寄出，假装系统存在
拼凑式	Groupon	WordPress 博客 + FileMaker 生成优惠券 PDF + Apple Mail 群发

做 MVP 要关注差异性：要的不是 10% 的改进，而是 10 倍的改进。Gmail 推出时别家邮箱只有 4MB 容量，它直接给 1GB，外加 Ajax 对话视图——至于富文本编辑器这些"标配"，反而都没有。初代 iPhone 同理：没有应用商店、没有 GPS、没有 3G，甚至没有复制粘贴，但多指触控的体验比别人好 10 倍。

最后是 Y Combinator 最著名的建议：创业须从无法规模化的事情做起。Airbnb 创始人挨家挨户招募房东并亲自帮拍公寓照片；Pinterest 创始人在咖啡店里挨个拉人试用；Wufoo 给每个客户手写感谢信。早期亲力亲为，是让公司这台小机器转动起来的唯一办法。

第 4 章数据与营销

数据部分的核心工具是 Dave McClure 的海盗指标 AARRR：

flowchart LR
    A["获取<br/>用户从哪来"] --> B["激活<br/>首次体验好吗"]
    B --> C["留存<br/>用户会回来吗"]
    C --> D["推荐<br/>用户会传播吗"]
    D --> E["收益<br/>能赚到钱吗"]
    F["神奇数字<br/>先行指标"] -.-> C

每个指标都要按渠道分解，且客户生命周期价值（CLV）必须大于获客成本。

“神奇数字"是本章最有趣的概念：找到那个"用户一旦突破就会粘住"的先行指标。Facebook 的是注册 10 天内加 7 个朋友；Twitter 的是关注 30 人；Slack 的是团队累计交换 2000 条消息（达到的团队 93% 会留存）。找到它的方法：定成功指标 → 找相关行为 → 回归分析 → 用 A/B 测试验证因果（相关不等于因果）。

数据驱动开发的正确姿势，是把功能当实验：

flowchart LR
    A["开发 MVP"] --> B["A/B 测试"] --> C{"分析结果"}
    C -->|"有效但不够好"| A
    C -->|"有效"| D["发布"]
    C -->|"无效"| E["放弃"]

书中的例子：LinkedIn 订阅页做过一次分桶测试，4 张不同的人物照片随机分 4 组，结果"灰白头发男士"那张显著胜出——“仅用一个测试代替直觉，就让我们赚到更多钱”。反例是 Etsy 式的做法：花大力气做完功能开庆祝派对，20 个月后默默删掉。

营销部分的第一个认知冲击是：最好的产品未必胜出，是"客户认为最好的产品"胜出。TiVo 发明了 DVR、用户忠诚度极高，2008 年市占率却只有 6%——94% 在有线电视公司手里。Peter Thiel 说得很直白：“没有销售方法的发明就是糟糕的生意。”

四大营销渠道：

口口相传：做出值得谈论的产品（Seth Godin 的"紫色的牛”）；极致客服——Zappos 全员接客服电话，Stripe 工程师每两周轮班客服，KAYAK 干脆把客服电话线装在工程师座位中间；病毒式循环。
病毒系数的数学：K = 每用户邀请数 × 转化率。K=0.5 时用户量翻倍，K=0.67 三倍，K≥1 才是指数增长但现实中不可持续（消费互联网产品 K 值 0.15-0.25 已属不错）。经典案例：PayPal 推荐朋友双方各得 10 美元，用户日增 7%-10%；Hotmail 每封邮件底部自动附一句"来 Hotmail 获取你的免费邮箱"，6 个月增 100 万用户。
市场推广：广告、公关、邮件、SEO、社交媒体、集客式营销。亮点案例：LinkedIn 2011 年的"一年回顾"个性化邮件，点击率超过 100%（有人点了不止一次）。
销售：按客单价分层——1000 美元以下自动化销售，1000-10 万美元内部销售，10 万美元以上外部销售。招人之前，创始人应该先亲自销售。
品牌化：品牌不是 logo，是客户与你所有交互的总和。红牛卖的不是饮料而是极限运动（赞助 Felix Baumgartner 从 38 公里高空跳伞，时速超 1280 公里）。

第二部分：技术

第 5 章技术栈的选择

本章的黄金法则只有一句：好的技术栈，其扩展速度要快于维护所需的投入。 如果用户翻倍只需要加几台服务器，就是好状态；如果需要把团队人数翻倍才能应付，就该重新评估了。

初始技术栈怎么选？答案朴素得让人意外：熟悉什么就用什么。LinkedIn 用 Java、GitHub 用 Ruby、Twitter 用 Rails、Pinterest 用 Python——全因为创始团队最精通它。早期用户和代码都少，可扩展性根本不是挑战，快速迭代才是王道。

技术栈是进化出来的，不是设计出来的。LinkedIn 2011 年用增量式四阶段法迁移到 Play 框架（找痛点和早期采纳者 → 最小集成点 → 重写一个服务 → 循环），最终 80 多个服务完成迁移；Twitter 从 Ruby 迁到 JVM 后搜索延迟降到 1/3。作者严厉警告不要"停止一切、彻底重写"——这是"所有软件公司都可能犯的单一最糟糕的战略性错误"，正确做法是渐进主义：把大改动拆成每步都有独立价值的小步骤。

自研、买商业产品还是用开源？书中给出了现成的决策树：

flowchart TD
    A["需要一项新技术"] --> B{"它是你的商业<br/>竞争优势吗？"}
    B -->|"是"| C["内部实现<br/>（或实现后开源）"]
    B -->|"否"| D{"有开源项目满足<br/>大部分需求？"}
    D -->|"是"| E["使用开源"]
    D -->|"部分满足"| F["使用开源<br/>并贡献补丁/插件"]
    D -->|"否"| G{"有商业产品<br/>可满足？"}
    G -->|"是"| H["购买"]
    G -->|"否"| C

还有一份"永远不要自己实现“的清单：安全（加密、密码存储）、Web 框架、数据库、消息队列、版本控制、构建部署工具、通用数据格式库、日期时间库、操作系统、编程语言。例外只有两种：为了学习，或者这就是你业务的核心竞争力。密码存储务必"盐 + bcrypt”，这类基础错误不值得任何公司再犯一次。

数据库的结论同样朴素：关系型数据库是默认答案。理由有三：通用数据存储技术需要十年才能成熟（NoSQL 在成书时平均年龄只有 6 岁）；数据是业务中寿命最长的部分，比任何功能甚至公司本身活得久；“好的数据存储是无聊的”。Facebook 用 4000 个 MySQL 节点每秒处理 6000 万次查询，证明关系型数据库可以走得很远；反例是 Pinterest 在月页面访问从零到上百亿的过程中放弃了 MongoDB 和 Cassandra——打败它的不是性能，而是复杂的故障模式。真要扩展，按复杂度逐级升级：优化查询 → 加缓存 → 主从复制 → 垂直分区 → 水平分片。

第 6 章整洁的代码

本章开篇点题：程序员的工作不是写代码，而是理解代码。编程时间中读代码与写代码的时间比超过 10:1，写代码的时间里 80% 以上是在维护旧代码——一天 8 小时，能写 5 分钟新代码就不错了。所以整洁代码就是"为人的理解而优化"的代码。

书中用一段 30 行的糟糕 Java 代码（把 CSV 转 JSON 的 BookParser）作为贯穿案例，逐节重构，覆盖：

代码布局：2014 年 Apple 的 “goto fail” SSL 漏洞是最好的反面教材——一行重复的 goto fail; 因为缺大括号、缩进误导，跳过了关键的安全验证，让数以百万计的设备暴露于中间人攻击。布局不是美观问题，是安全问题。
命名四原则：回答所有重要问题、要精确、要全面、遵循约定。一个好例子是把变量命名为 totalWeightInLbs——单位编码进名字里，“千克加磅"的 bug 自己就会现形。
错误处理：绝不静默吞异常，空的 catch 块会让调试变成猜谜。
DRY：最大的重复是重新发明轮子，用久经考验的开源库替代手写解析。
单一职责原则：函数名长到可笑（convertCsvToJsonAndDeleteCsvAndGenerateReport）就是职责过多的信号。
函数式编程三件套：不可变数据、高阶函数、纯函数。副作用无法消灭，但要隔离到应用入口。
松耦合与高内聚：依赖反转原则——高层与低层模块都依赖抽象；类名带 “Util” 是低内聚的典型特征。判断耦合紧不紧的快速方法：试着写单元测试，测试要复制多少实现细节，耦合就有多紧。

关于注释和重构的两句话值得抄下来：“不要为糟糕的代码注释——重新写吧。"（Kernighan & Plauger）；重构不是单独的"清理阶段”（这样的阶段永远不会到来），而是编码的核心活动——先做纯粹重构，再做纯粹扩展。

第 7 章可扩展性

可扩展性不是布尔属性，它分两个层面：编码实践的扩展和性能的扩展。创业像开手动挡：太早扩展（低速挂高挡）会熄火，太晚扩展（低挡猛踩油门）会过热。早期重点应放在编码实践上。

四大编码实践：自动化测试、代码分离、代码评审、文档。

自动化测试：TDD 的真正价值是设计反馈——先写测试会提前暴露设计问题。但作者很务实：创业早期可以合理地跳过测试（早期产品 10 款里 9 款会被抛弃），但支付、安全、数据存储类代码从第一天起就必须大量测试。权衡三要素：bug 的成本、bug 的可能性、测试的成本。
代码评审：数据惊人——有评审的代码每 100 行 0.82 个错误，无评审 4.5 个（降低 80% 以上）；设计+代码评审能抓住 55%-60% 的 bug，而单元测试和集成测试只能抓 30%-35%。结对编程多花约 15% 的时间，换约 15% 更少的缺陷。
文档：RDD（Readme 驱动开发）——写代码之前先写 Readme，写作是更严密的思考形式，能在写几千行代码之前暴露计划的瑕疵。

性能扩展的方法论是"测量 → 优化"的迭代，顺序是 Kent Beck 那句”让它工作，让它正确，让它快速"——顺序不可颠倒。书中用链表 vs 数组的实验证明直觉和大 O 分析都会骗人（数组因 CPU 缓存一致性快了 50-100 倍）。记住一组"每名程序员都应知道的延迟数字"（内存引用约 100ns、磁盘寻道约 4ms、同数据中心往返约 0.5ms），很多优化决策用算术就能算出来——何况程序员的时间比 CPU 时间贵三个数量级，买硬件常常比改代码便宜。

第 8 章软件交付

本章两个核心观点：“完成"意味着交付（代码跑在你电脑上不算完成，交到用户手里才算）；以及 Martin Fowler 那句反直觉的方法论——“如果你觉得痛苦，就多去做”。降低交付痛苦的办法不是回避，而是更频繁地面对：频繁合并（持续集成）、频繁部署（持续交付）。

完整流水线长这样：

flowchart LR
    A["版本控制"] --> B["构建工具"]
    B --> C["持续集成<br/>CI 服务器守门"]
    C --> D["配置管理<br/>容器 / 编排"]
    D --> E["自动化部署<br/>金丝雀 → 滚动全量"]
    E --> F["监控<br/>日志 / 指标 / 报警"]
    F -.->|"反馈"| A

本章最震撼的案例是 LinkedIn 的手工交付恐怖故事：2011 年 LinkedIn 上市、会员每秒增加 2 个，但发布流程是"火车模型"两周一班；发布前三周，十几个团队合并功能分支如同噩梦；构建一次要 10 小时且测试间歇性失败；部署计划是手工维护的 wiki 页面，人肉在几千台服务器上滚动部署几百个服务，发布常拖到深夜甚至中途取消。到 2011 年底，公司几乎无法发布软件了。于是启动"项目反转”（Project Inversion），全面转向基于主干的开发、自动化和持续交付，最终做到一小时内多次部署且 bug 更少。

支撑这种规模的两个关键技术：

基于主干的开发：不用功能分支，大改动靠"抽象分支"（先定义接口、增量迁移、再切换实现）和"功能开关"（未完成代码默认关闭，可 1% → 10% → 100% 渐进放量）。LinkedIn 借此从 100 名工程师扩到 500+；Google 支撑 15000+ 开发者、每分钟 20-60 次提交。
监控三支柱：日志（格式化、含时间戳和唯一请求 ID、对 grep 友好）、指标（可用性 → 业务 → 应用 → 进程 → 代码 → 服务器六个层次）、报警（监控数据没人看就等于没有）。LinkedIn 高级副总裁 David Henke 的话：“如果你无法测量，你就无法修复。”

第三部分：团队

第 9 章创业文化

文化胜过战略：点子、规划、产品都会失败，伟大公司的核心是伟大文化——一种能不断产生新点子、新规划、新产品的环境。注意，文化不是桌上足球和圣诞派对，“文化是行动，而非口号”。

核心理念 = 使命 + 核心价值。好的使命宣言要简洁、清晰、永恒、鼓舞人心。Simon Sinek 的"黄金圆"是最好的解释工具：

flowchart LR
    subgraph 普通公司["普通公司：由外而内"]
        A1["做什么"] --> A2["怎么做"] --> A3["为什么"]
    end
    subgraph 伟大公司["伟大公司：由内而外"]
        B1["为什么"] --> B2["怎么做"] --> B3["做什么"]
    end

“人们不想买你做的产品，想买的是你的信念。“马丁·路德·金讲的是"我有一个梦想”，而不是"我有一个计划”。

核心价值不是拍脑袋选出来的，而是从团队身上发现的——判断标准是"即便不再缺钱、即便一百年后、即便因此被华尔街惩罚也要坚持"。“宽松着装规定"过不了这个测试，“透明沟通"可能过得了（Buffer 公开所有员工薪水、股权甚至投资人协议，公开薪酬后那个月收到的简历翻倍）。

关于激励，本章引用了经典的"蜡烛问题"实验：给金钱奖励的一组比无奖励组平均慢 3-5 分钟——外在奖励对创造性工作适得其反。正确的环境要放大三个内在要素：

flowchart LR
    A["自主权<br/>Google 20% 时间<br/>LinkedIn 黑客日"] --> M["内在激励"]
    B["专业能力<br/>刻意练习<br/>导师制"] --> M
    C["目标<br/>使命感<br/>任期制"] --> M

几个让人印象深刻的公司实践：Valve 无管理、无头衔、桌子带轮子让员工"用脚投票"选项目，400 名员工人均产值超过 Google；Travis CI 规定每人每年至少休 25 天带薪假，因为"休假比离职补偿金便宜”；Zappos 给新员工开 2000 美元"退出奖金”，最终不到 1% 的人拿钱走人。

第 10 章求职之路

这一章是写给打工人的，核心事实：80% 的工作不登广告。招聘网站投递的录用率约 1/100，而人脉引荐的录用率约 1/7——所以找工作的时间应该 80% 花在人脉上。

LinkedIn 三度人脉的数学很有说服力：50 个联系人 × 50 × 50 = 125,000 个三度关系。发展人脉的途径包括 Meetup、黑客马拉松（“几乎每次编程竞赛实质上都是一次招募活动”）、演讲、博客、开源。一个经典案例是 Meebo 联创 Elaine Wherry 的"招聘蜜罐"实验：她虚构了一份 JavaScript 工程师简历，挂在网上无人问津，一放上 LinkedIn 立刻爆炸——总计收到 172 个组织、382 位招聘人员的 530 封邮件，平均每 40 小时一封。

评估工作机会的顺序是人 → 业务 → 经济回报（“人们不是离开公司，而是离开经理”）。报酬部分最有价值的是股权科普，典型的 4 年兑现结构：

flowchart LR
    A["入职 0%"] --> B["满 1 年 cliff<br/>一次性兑现 25%"]
    B --> C["余下 75%<br/>分 36 个月均分"]
    C --> D["行权<br/>按授予时 409A 价格"]
    D --> E["IPO 或收购退出"]

作者用同一笔投入（年薪差 1.5 万 × 4 年 + 行权 1 万 = 7 万美元）算了三档退出回报：公司像 Flickr 那样 2200 万被收购 → 回报 8.55 万；像 Photobucket 那样 2.5 亿被收购 → 92 万；像 Instagram 那样 10 亿被收购 → 373 万。再结合 75% 的失败率——这就是"股权是一张彩票"的全部含义。Facebook 工程师 Daniel Kim 坦白：他差点因为 Oracle 薪水更高而拒绝 Facebook，因为"我不知道股权是什么"。

谈判要点：想要 +10% 就开口要 +15%；不要透露当前薪水；没写进合同的承诺当作不存在；最强的筹码是竞争性 offer 和"离开"的底气——面试工作的最好时机，是你不需要工作的时候。

第 11 章招兵买马

站在创业者视角的镜像章节。第一条建议出人意料：先别招。更多人 = 资金消耗更快、决策更慢；关键问题不是"招了人能做什么"，而是"不招人就做不到什么"。

关于合伙人：Paul Graham"杀死创业公司的 18 个错误"第一条就是单一创始人；两个创始人最好，超过三个易生内耗；最佳合伙人是共同战斗过的前同事；股权应平均分配并加兑现计划（YC 最好的公司中没有一家股权分割显著不均）。

关于"10 倍程序员"，作者给出了全书最清醒的解读：研究确实发现程序员效率差一个数量级，但 10 倍程序员不是打字快 10 倍，而是10 倍能力的决策者——做更好的技术决策，避免几个月的无效苦干。而且表现因任务和环境而异（文化契合决定他是 10x 还是 0.1x），人可以变好。所以正确的策略是成为培养 10 倍程序员的公司，而不是妄想只招摇滚明星。

面试环节的数据同样颠覆：Google 研究 1 万次面试后发现面试官评分与后续工作表现"一点关系都没有"，智力题（“一架飞机能装多少高尔夫球”）完全是浪费时间。更真实的替代方式是一个谱系：BYOL 自带笔记本实操 → 带回家的挑战 → 真实业务问题 → 结对编程 → 试用一天。招聘流程上，每位面试官只准说"可以"或"不可以"，不允许"也许"，一票否决——录用错的人比错过对的人更糟。

两个暖心的案例收尾：Airbnb 创始人花近 6 个月、面试数百人才招到最初的员工；Zappos 所有新员工（含会计、律师）都要上 4 周客服培训并实际接 2 周电话——文化不是贴在墙上的，是筛选出来的。

第 12 章学习

最后一章讲的是程序员职业的底层操作系统。软件行业知识每年都在淘汰，Erlang 之父 Joe Armstrong 的建议是：花 20% 的时间学习——这是一种复利。

一万小时定律人人听过，但作者强调光有时间不够，还要刻意练习：有反馈机制 + 每次挑战超出当前能力的任务。刻意练习"是乐趣的对立面"。

“没时间学习"是伪命题——说这话其实是在说"我把别的事排在学习前面”。作者亲证：每晚 11 点学 20-40 分钟，2006 年学 Ajax → 2007 年进 TripAdvisor；2008 年研究雪碧图 → 2009 年进 LinkedIn；2010 年研究 Web 框架 → 2011 年负责重建 LinkedIn 的 Web 框架基础设施。

学习的三个技巧构成一个闭环：

flowchart LR
    A["研究<br/>读书 / 论文 / 课程<br/>读开源代码"] --> B["实现<br/>业余项目 / 开源贡献<br/>刻意练习"]
    B --> C["分享<br/>写作 / 演讲 / 开源"]
    C -.->|"反馈与新机会<br/>驱动新的研究"| A

“分享"是回报最被低估的一环，作者列了五重回报：专业性（教是最好的学）、质量（家里最干净的时候是客人来之前——开源前你会补测试写文档）、劳动力（用户报 bug 是免费 QA，提交补丁是免费开发）、市场推广、所有权（博客和开源成果一辈子跟着你）。作者和同事做过"30 天博客挑战”，每人每天写一篇，一个月后博客流量涨了 10 倍，文章两次登上 Hacker News 首页，甚至推动 Play/Scala 社区根据他的反馈改了 API。

全书的落脚点很朴素：学习的目标不是成为世界上最出色的程序员，而是成为比昨天更出色的程序员。“好程序员与差程序员的差别和天赋关系不大，更多与坚持有关。”

总结：这本书值不值得读

如果把全书压缩成一张图，创业公司的打造过程就是三个循环的叠加：

flowchart TD
    subgraph 产品循环
        P1["验证问题"] --> P2["构建 MVP"] --> P3["数据验证"] --> P1
    end
    subgraph 技术循环
        T1["整洁代码"] --> T2["测试与评审"] --> T3["持续交付"] --> T1
    end
    subgraph 团队循环
        M1["定义文化"] --> M2["招兵买马"] --> M3["持续学习"] --> M1
    end
    产品循环 --- 技术循环
    技术循环 --- 团队循环

这本书的优点：

全面：产品、技术、团队三大块一次讲透，是名副其实的"创业者的 Hello, World"。
案例扎实：几乎每一个论点都有真实公司、真实数据支撑，LinkedIn 的一手经验尤其珍贵。
立场清醒：不贩卖创业鸡汤，幂律分布、75% 失败率、“你大概率不会变富"都摆在明面上。

局限也很明显：成书于 2016 年，技术栈部分的具体工具（如 Chef/Puppet 时代的配置管理）已有年代感，但其方法论——渐进主义、持续交付、决策树——至今没过时。

推荐给三类人：想创业但不知从何开始的程序员（读全书）；在大公司想理解创业公司运作方式的工程师（读第 1、4、8 章）；要带团队或正在带团队的技术管理者（读第 6-9、11 章）。

团队建设 on 方糖猫Blog

《奔跑吧，程序员》全书导读：从零开始打造产品、技术和团队

《奔跑吧，程序员》全书导读：从零开始打造产品、技术和团队

这本书是什么

第一部分：产品

第 1 章 为何创业

第 2 章 创业点子

第 3 章 产品设计

第 4 章 数据与营销

第二部分：技术

第 5 章 技术栈的选择

第 6 章 整洁的代码

第 7 章 可扩展性

第 8 章 软件交付

第三部分：团队

第 9 章 创业文化

第 10 章 求职之路

第 11 章 招兵买马

第 12 章 学习

总结：这本书值不值得读

第 1 章为何创业

第 2 章创业点子

第 3 章产品设计

第 4 章数据与营销

第 5 章技术栈的选择

第 6 章整洁的代码

第 7 章可扩展性

第 8 章软件交付

第 9 章创业文化

第 10 章求职之路

第 11 章招兵买马

第 12 章学习