阅读感悟

暂略

阅读摘录

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

叶夫根尼·布里克曼
194个笔记

1.2 什么是科技创业公司

◆ 创业公司就是在极度不确定的条件下创造新产品或服务的人类组织。——Eric Ries, 《精益创业》

◆ 创业公司的目标在于快速增长。一家公司成立的时间短并不能让其本身成为创业公司，创业公司也未必要从事科技领域的工作，未必要接受风险投资基金或有某种“退出”的机制。创业公司唯一必不可少的东西就是增长，其他和创业相关的所有东西都是伴随着增长而来的。——Paul Graham, Y Combinator联合创始人，硅谷创业教父，《黑客与画家》作者

◆ 成熟企业拥有的产品已经被市场证明是为大家所接受的，所以它们关注的是扩大规模、优化产品和提升执行效率。而创业公司并不知道什么样的产品能在市场中立足，所以公司的主要注意力将放在试验、尝试和纠错上，重点是寻找一种可重复、可扩展的商业模型

◆ 可以这么说，创业公司的最后一个要素就是它们是按探索模式运作的

◆ 科技创业公司”是具有下述特征的组织。·产品：技术。·环境：极度不确定。·目标：大幅增长。·运作模式：探索。

◆ 这本书的内容既可以用在全新的只有3个人的公司上，也可以用在有着3000人规模的成熟公司新成立的创新机构上。只要你进行的是技术研发，环境总处于变化之中，主要目标是为了增长，机构是以探索的模式在运行，那么书中的内容就适合你

1.3 为什么应该在创业公司中工作

◆ 要在科技创业公司中工作，甚至自己创立这样一家公司，我们应该考虑三个主要因素：更多的机会、更多的所有权以及更多的乐趣。

◆ 一直以来，我们的大脑和身体都通过各种人造部件和技术得到增强。这种情况潜移默化地发生，让人无法觉察

◆ 换句话说，就像Marc Andreessen在2011年预测的那样——“软件正在蚕食世界”。因为科技愈加无所不在，软件公司将会占据越来越多的产业

◆ 也可以使用New Relic、KISSMetrics或者MixPanel，而不用去研发自己的监控软件；可以使用Amazon SES、MailChimp或者SendGrid，而不用去搭建自己的email服务；如果需要logo，可以使用DesignCrowd；如果需要法律服务，可以使用RocketLawyer；如果需要接受付款，可以使用Stripe；如果需要管理客户数据，可以使用Salesforce；如果需要提供客户支持，可以使用Zendesk。

◆ 我们的父母或祖父母很可能会在同一家公司工作50年，顺着职业的阶梯不断攀爬，戴着金表退休[插图]。现在，我们再也享受不到这种待遇了，因为那种工作已经消失了。据统计，美国60年代初期出生的大多数人会在18～46岁从事11.3份工作，这个数字可能在不断地上升，20世纪80年代初期出生的大多数人到26岁时已平均从事了6.2份工作。从第一个数字可以算出，平均一份工作的持续时间还不到3年。大公司的工作并不比小公司的工作更稳定。例如，仅仅在2014年，思科就解雇了6000名员工，IBM解雇了13000名员工，微软解雇了18000名员工，HP则解雇了27000名员工。所以，所谓的工作稳定性已经不复存在。

◆ 我在大学毕业正决定去哪儿的时候得到了一条建议：你应该把硅谷当作一家大公司，其中有Facebook部门、Google部门和一大堆小型创业部门

◆ 真正的风险并不是因加入了小型创业公司而失业——毕竟我们在大公司工作也没办法保证不失业——而是失去机会的风险

◆ 可能某一天要编写数据库查询，第二天又要设计用户界面，之后还得回复客户的服务邮件，中间又要腾出时间准备投资者的融资演讲稿，期间培养出的这些技能将对你今后的职业生涯大有裨益。你也会学到如何应对紧张、压力和风险，会被推出自己的舒适区之外，这才是你真正能学到东西的地方。这也就是为什么很多人在创业公司三个月要比在大公司工作三年学到的还多。

◆ 师综上所述，自主权、掌控力和使命感是激励人的三个最强有力的因素

◆ 如果你找到了一份可以同时提供这三者的工作，那么就是找到了一份你会热爱的工作，也是一份你可以为之自豪的工作

1.5 小结

◆ 在你成长的过程中，人们总是会告诉你：这个世界就是……尽量不要撞了墙也不回头，要努力拥有美好的家庭，要学会享乐，要存下一点钱。那是一种非常有限的生活。生活可以变得更加多彩，只要你发现这样一个简单的事实：你周围的一切，即你所谓的生活，都是由不如你聪明的人组成的，你可以去改变它，可以去影响它，也可以做出自己的东西供他人使用。一旦意识到这一点，你将从此不同。——史蒂夫·乔布斯

2.1 点子从何而来

◆ 点子也不会凭空发展进化出来，物理学的能量守恒定律阐述了能量从来不会凭空产生或湮灭，而是以不同的形式被重新利用，点子也同样遵守这样的守恒定律，所有新的想法只不过是现有想法组合而成的结果

◆ 。但真实的情况是“我们都在用相同的材料做东西”（弗格森语），混搭和重新合成是产生新点子的常见方法[插图]。那是因为创造力的产生可以归结为三个阶段，这三个阶段都不过是不同形式的重新合成：（1）模仿；（2）转换；（3）合并。

◆ 如果我们想要找到创业的好点子，就需要一整堆的“原料”，从而可以在此基础上去研究、注明出处、重新合成、聚合和转换，也就是说，我们需要掌握大量的知识

◆ 其目标，正如史蒂夫·乔布斯所说的，就是努力“让自己感受人类最美好的东西”。

◆ 纵观人类历史，出现了不少多重发现（multiple discovery）的例子，即有两个或多个科学家或发明家在差不多相同的时间内提出相同的想法，比如牛顿和莱布尼茨都在17世纪发表了关于微积分最早的论文，达尔文和华莱士都在19世纪提出了进化论，而格雷和贝尔在同一天提交了电话的发明专利申请。这一切都不是偶然，它表明环境对新点子的涌现有巨大影响

◆ 如果你深深沉浸在某一个主题中，日复一日致力于此，你的潜意识除了解决问题就不干别的了。也许在某天清晨或者午后醒来，你就找到了答案。对于那些并没有想方设法、全心投入解决现有问题的人，潜意识就会在其他事情上“游手好闲”，不可能有什么大作为。所以自我管理的方法就是一旦你有什么真正重要的问题，就不要把其他事情置于自己注意力的中心，你要一直把心思放在这个问题上。让你的潜意识保持在“饥饿”状态，不得不解决你的问题。这样你就可以平静地入睡，等待清晨醒来时得到答案，得来全不费工夫。——Richard Hamming, You and Your Research演讲

2.2 验证

◆ 精益和敏捷方法的核心原则就是尽可能快地把可用的产品放在用户面前，即便产品离最终完成还有很远的距离。相反，瀑布方法则是希望先做出完整的解决方案，再呈现给用户

◆ 在《四步创业法》一书中，Steve Blank描述了一种叫客户开发的过程，该过程应该和产品开发过程同时进行

◆ 我们应该在第一天就把客户纳入开发过程当中，而不是等到产品完成了，才考虑它有没有客户

◆ 客户验证是指，承认我们的产品点子只不过是需要测试的、未经证明的假设，这样的测试必须以尽可能快、尽可能低的成本对真实客户实施。越早向同事之外的人验证你的点子，成功的概率就越大

◆ 可以分解为以下三个连续的阶段[插图]。第一步：验证问题确保找出客户实际面临并且痛苦到愿意掏腰包去解决的问题。第二步：验证MVP实现潜在解决方案的最简可行产品（minimum viable product, MVP），让少量客户购买该产品进行验证。第三步：验证产品把MVP完善为完整的产品，让更多客户去购买，对可扩大化的商业模式进行验证。

◆ 医生想要更多的病人，而不是更有效率的诊所

◆ 高效的诊所就会有更多的病人，但是关注错误的问题会导致整个公司误入歧途

◆ 关注了错误的问题就意味着所有的产品、市场营销策略和促销材料全都是错误的

◆ 在思考问题的大小时，有三个方面需要考虑：频率、密度和痛苦程度。

◆ ·频率：你所解决的问题经常发生吗？·密度：有很多人都会面临这个问题吗？·痛苦程度：该问题只是让人讨厌，还是绝对必须解决？

◆ 考虑市场规模有一个好方法，就是考虑建立一家赚得10亿美元收入的公司的几种方法。·以1美元的价格销售10亿件产品：可口可乐（罐装汽水）；·以10美元的价格销售1亿件产品：强生（家用产品）；·以100美元的价格销售1000万件产品：暴雪（《魔兽争霸》）；·以1000美元的价格销售100万件产品：联想（笔记本电脑）；·以1万美元的价格销售10万件产品：丰田（汽车）；·以10万美元的价格销售1万件产品：Oracle（企业级软件）；·以100万美元的价格销售1000件产品：Countrywide（高端金融抵押公司）。——Balaji S. Srinivasan，斯坦福创业项目工程课程

◆ 由丰田的创始人丰田喜一郎所提倡的，就是五个为什么

2.3 小结

◆ 许多数学家更喜欢因为问题固有的美而去研究问题，而非这些问题有什么实际的好处

3.1 设计

◆ 在顾客看来，界面就是产品。——Jeff Raskin, 《人本界面》

◆ Joel Spolsky把这种情况叫作冰山的秘密。我们所看到的冰山在水面上的那部分只占它总体积的10%；同样，我们可以看到和触碰到的产品的那部分——用户界面，只占全部工作的10%。所以，这个秘密就是大多数人并不清楚这一点。

◆ 以用户为中心的设计应该纳入我们的产品开发过程中，下面是它的五个基本原则：·用户故事；·人物角色；·情感设计；·简单；·可用性测试。

◆ 所谓用户故事，就是从用户的角度简短地描述你所做的东西。它应该回答下面三个问题。·用户是谁？·他们要实现什么？·他们为什么需要？

◆ 如果你是一名程序员，想理解你的用户会更加困难。每个人都会对“一种产品如何工作”形成自己的概念模型。但程序员的模型通常是非常细节化的，一般都处于界面、事件、消息、API、网络协议和数据存储这样的层次，而典型的用户模型通常没有那么多的细节，既不精确也不完整（例如，许多用户是不能区分软件与硬件、显示器与电脑有什么差别的）。这种概念模型上的不匹配会导致程序员很难和用户沟通。

◆ 许多程序员并没有意识到，因为对自己的软件非常了解，所以考虑软件的方式和用户是完全不同的，我们全然记不起初学者面对我们的软件是什么感觉。这种情况称为知识之祸，

◆ 作为程序员，当你在设计软件的时候，你的大脑其实一直都在“听着歌曲”。然而，你的用户却什么都没有听到，他们必须通过你所设计的用户界面（user interface, UI）去使用软件

◆ 你不能期待用户知道你所知道的，你也不能指望用户通过文档或教程来填补这一鸿沟

◆ 正如Steve Krug所说的：“关于说明书你必须知道的最主要的一件事就是，没有人想读说明书。”

◆ 想要做出成功产品的唯一选择就是做出出色的设计

◆ 大多数设计给程序员使用的软件也是设计给电脑用的，而电脑可不在乎可用性的问题

◆ 要成为一名成功的程序员，就得对糟糕的设计有很强的容忍力，几乎要到熟视无睹的地步

◆ 但如果要开发普通人可以使用的软件，就必须和他们一样去感同身受，压制自己作为程序员的许多本能感受

◆ 编程的过程和制作易用产品的过程是格格不入的，简单来说就是程序员的目标和用户的目标是有显著差别的。程序员希望构筑产品的过程顺利简单，用户则希望与程序的交互顺利简单。而这两个目标通常都不会共生于相同的程序。——Alan Cooper, The Inmates Are Running The Asylum

◆ 即便你克服了理解用户的障碍，还会面临第二个问题：他们希望实现什么

◆ 最常见的设计错误就是把用户的目标（他们要实现的是什么）和任务（他们可以如何实现）混淆了

◆ 经典的例子来自于冷战时期的太空竞赛，NASA的科学家意识到无法在太空的微重力环境下使用钢笔，所以花了数百万美元研发出一种带有加压墨盒的钢笔，它可以在零重力、上下颠倒、水下以及高温严寒等各种环境下书写。与此同时，苏联人使用的却是铅笔

◆ 这个故事虽然只是个传闻，但它却精彩地说明了当我们无视根本目标，而对做事情的某个特定方法过于关注时，会有什么荒唐的事情发生

◆ 正如亚伯拉罕·马斯洛所说：“如果你唯一的工具是一把锤子，那么你看到的任何东西都像钉子，我想这对人们是很有诱惑力的。

◆ 把任务从目标中分离出来的一种最佳方法就是使用上一章介绍过的“五个为什么”技巧（阅读2.2.3节了解更多信息）。

◆ 要区分任务和目标之间的差异，有一种很简单的方法。任务会随着技术的变化而变化，但目标有一种讨人喜欢的属性——它会非常稳定。例如要从圣路易斯到旧金山旅行，我的目标始终是速度、舒适性和安全。但在1850年去加州金矿的话，我会在全新的高科技科内斯托加马车中度过这段旅程。为了安全，我还会带上温切斯特来复枪。而在1999年从圣路易斯到硅谷，我会乘坐最新的高科技波音777飞机。——Alan Cooper, The Inmates Are Running The Asylum

◆ 第三个问题“为什么人们需要它”实际上就是强迫你证明为什么你要做你所做的东西，这就是上一章介绍的客户开发过程可以发挥作用的地方（阅读2.2.2节了解更多信息）

◆ 如果该产品或功能并不能为真正的用户解决重要的问题，你就不应该浪费时间去实现它。

◆ 无论什么时候，我们都应该花些时间用书面方式回答这三个用户故事问题，把你的产品点子从脑海中短暂、模糊的想法转变成纸面上具体的文字和图示，这样可以暴露出你在问题理解上存在的一些缺陷

◆ 在Readme文件、维基系统或便利贴上记录几行文本、画出几幅草图，就可以促使自己从用户的角度去感受这种端到端的体验，确保自己知道自己在做什么，为谁做，以及为什么值得做

◆ 这里有另一种可以显著提升设计技能的快捷方法：不要再为“平均的人”设计产品。人平均下来就是不洋不土、不男不女，如果你为平均的每个人做设计，那么谁都不会喜欢你设计出的东西

◆ 真正的平均用户被保存在日内瓦国际标准局的密不透气的地下室中。——Steve Krug, 《点石成金》

◆ 你关注的目标越广泛，错失靶心的必然性就越大

◆ 想让大量人口中50%的人满意你的产品，从而实现50%产品满意度的目标，这种做法是行不通的。我们只能挑选出50%的人，想方设法让他们100%满意，才能实现我们的目标。我们甚至可以瞄准市场中10%的人，让他们100%地心醉神迷，从而取得更大的成功。这听起来可能有点违背我们的直观感觉，但为单个用户进行设计是满足广大人群需求最有效的方式。——Alan Cooper, The Inmates Are Running The Asylum

◆ 人物角色之所以是如此强有力的设计手段，是因为它可以促使你去考虑真正的人，估计他们的真实需求、局限性和个性，最为重要的是，考虑他们的情感

◆ 研究表明，人与计算机及软件之间的交互在很大程度上与人类之间的交互类似

◆ 我们大部分的情感反应是自动产生的，控制这些反应的大脑区域尚未进化到能够对人和举止像人的无生命物体进行区分的程度

◆ Mailchimp把它的吉祥物（一只穿着像邮递员的猴子）放在了几乎所有的页面上，Tumblr的停机页面显示的是一只叫Tumblebeast的神奇小野兽在机房里发泄破坏，而Twitter的停机页面则是一只“失败鲸”（见图3-2）。

◆ 设计的情感因素对用户而言就像功能因素一样重要

◆ 你的产品是能说话的——每天24小时都在和你的客户交谈。——Jason Fried、David Heinemeier Hansson、Matthew Linderman, Getting Real

◆ 只要有可能，我们就应该把软件设计得像把你记在心上、考虑周到的人一样。要记住用户的参数设置，记住他们上次使用你的软件做了什么事情，记住他们过去搜索了什么东西，要尝试使用这些信息预测用户在以后会做什么事情

◆ 响应能力也没必要做得太过花哨，经常被忽视的一种最简单的设计元素，就是要提供基本的反馈

◆ 如果UI没有给出反馈，用户就不知道点击操作是否执行了，要么会连按10多次按钮，要么就失去信心完全放弃了

◆ 人都会犯错，而且还会不断犯错。在设计软件时，要假设用户也会输入错误、点击错误的按钮或者忘了一些重要的信息

◆ 这里不谈人为的错误，而是探讨沟通与交互：我们通常把糟糕的沟通或交互称为错误。当一个人与另一个人合作时，永远不要用错误这个词来形容另一个人的表达方式。因为每个人都希望能够理解他人的话语并做出回应，如果出现了无法理解或看似不恰当的地方，可以质疑，可以澄清，可以继续合作下去。那为什么人与机器之间的交互不能看作是合作呢？——Don Norman, 《设计心理学》

◆ 以下是一些经验法则，可以避免这种错误的发生。·提供帮助和指引，而不是错误消息。例如避免使用“错误”“失败”“问题”“无效”和“异常”这样的词，而是向用户解释程序希望获得的输入与用户的输入之间有什么差异。·在用户输入的同时进行检查（而不是在页面提交之后再进行），并分别给出肯定和否定两种反馈，给出的反馈应该在用户视线附近（而不是页面的顶部）。·永远不要把用户做好的东西弄丢。

◆ 除了显示有帮助的信息，我们也应该试着做出能在一开始防止错误发生的设计。在精益制造中，这种方法称为poka-yoke，这是一个日本术语，意思是“防止错误发生”

◆ 除了要对错误的状态进行处理，还要确保设计能够处理空白状态：应用程序就像用户第一次和它交互、什么数据都没有输入的样子

◆ 如果动态消息是完全空白的，新用户一定不觉得是很好的体验，他们可能不会继续使用你的服务

◆ 几乎所有的创新训练都有一个相同的目标：简单

◆ 《代码大全》的作者、程序员Steve McConnell在书中写道：“攻克复杂性是软件开发中最为重要的技术主题。

◆ Apple的首席设计师Jonathan Ive说：“简单之中蕴含着一种深刻而经久不衰的美。”每个人都在为简单而努力，问题是让事情简单并不是一件简单的事

◆ 我本来想把信写得简短一点，但我没有时间。——Blaise Pascal

◆ 正如Antoine de Saint Exupéry所言：“达到完美并不是没有东西可以添加，而是没有东西可以去除。”

◆ [插图]图3-8：简单（图片由Eric Burke提供）

◆ 在设计上做得比较成功的公司，均认识到加入软件中功能的数量并不受“瑞士军刀空间有限”那样的物理限制，而是受使用软件的人的心理限制

◆ 人们认为专注就是要对你关注的东西点头称是，但是事实并非如此。专注其实是要对其他一百个出现的好主意说不——所以你只能小心挑选。实际上，我对我们不做的事与我们做了的事一样感到自豪。创新就是对1000种东西说不。——史蒂夫·乔布斯

◆ 在这份教程中，我将主要关注两个例子：一是解决一份简历存在的设计问题，这是几乎所有人都非常熟悉的设计任务；二是从头开始设计一个网站（具体而言就是本书的配套网站hello-startup.net），其过程有点像典型的创业产品所需要经历的过程

◆ 实际上所有软件设计的真正核心几乎都是文案

◆ 伟大的界面是写出来的。如果你认为每一个像素、每一个图标和每一种字体都很重要，那么你也要相信，每一个字母都很重要。——Jason Fried、David Heinemeier Hansson、Matthew Linderman, Getting Real

◆ 好的艺术家模仿，伟大的艺术家偷窃。——史蒂夫·乔布斯

◆ 如果你不想立马跳到代码中，可以先使用线框图或原型工具，比如Balsamiq、UXPin或者Justinmind。利用这样的工具，可以从UI元素库拖拽出一些元素进行摆放，组合成一份设计

◆ 布局有一个要点就是亲密性，元素之间的亲近程度表明它们在逻辑上是否相关联。逻辑上联系在一起的元素应该更加接近，没有关联的元素则应该远离一些

◆ 作为经验法则，我们要尽量挑选一条明显的线，让所有东西都向它对齐。换句话说，不要把一些内容左对齐，而另一些内容右对齐，有些内容又居中对齐。另外，要谨慎使用居中对齐，因为这种方式在我们的大脑中并没有建立起一条明显的线，会让设计看起来更加业余。这也仅仅是一条经验法则，你当然可以偶尔打破它，但也必须是有意识而为之

◆ 排版就是安排文本的艺术与科学，目的是让文本易读和美观。这一节将关注排版最重要的几个因素：行宽、行距、字体和样式

◆ 行宽是指每一行的长度。如果文本行太短，读者就会太过频繁地被打断而跳到下一行。如果文本行太长，读者就没耐心把它读完

◆ 行距是行与行之间的垂直间距。和行宽一样，如果行距设置得太小或太大，文本的阅读都会比较困难。行距的最佳尺寸一般都是字体尺寸的120%～145%

◆ 总的来看，所有字型都可以分成五类：衬线字型、无衬线字型、装饰性字型、手写型和等宽字型

◆ 。衬线字型作为最古老的字型，不仅可以追溯到使用印刷术的年代，甚至可以一路追溯到古罗马人刻在石头上的字母。所以，如果想要有“传统的”感觉，就可以在标题中使用衬线字型

3.2 MVP

◆ 。执行是昂贵的，所以你需要尽可能低成本、快速地向客户验证你遇到的每一个新问题和想法。最好的方法就是实现所谓的最简可行产品（minimum viable product），或者叫MVP。

◆ [插图]图3-35：如何实现可行的MVP，图片由Henrik Kniberg提供

◆ 我问（我的客户）“如果产品是免费的，有多少人会真的购买或使用”的目的就是把价格因素抛开，看看产品本身是否能够让客户心动。如果做到了，我会接着问几个问题：“好了，这个产品不是免费的。事实上，假设我要收取你们100万美元，你们还会购买吗？”虽然这种对话听起来有点儿像开玩笑，但我一直在用这种方法。为什么呢？因为超过一半的时候，客户会像这样说：“Steve，你怕是疯了吧。这个产品不会值25万美元以上。”其实，我只不过想让客户告诉我，你们愿意支付多少钱而已。——Steve Blank, 《四步创业法》

◆ 在《创新的扩散》一书中，Everett Rogers把客户分成了5种类型。（1）创新者愿意承担新技术的风险，因为技术本身就是他们生活中的主要兴趣，不管功能如何，他们总是留心寻找最新的发明。（2）早期采用者也愿意承担新技术的风险，不仅仅因为他们对技术感兴趣，还因为他们很容易联想到该技术将会给生活带来什么样的好处。（3）早期的大多数客户是迫切需要解决具体问题的。他们能够想象到新技术是怎样成为解决方案的，但又知道许多新的技术革新最终都会失败，所以在自己购买新技术之前，他们更愿意等待，看看该技术是否能解决他人的问题。（4）后期的大多数客户也有需要解决的具体问题，但他们不喜欢使用新技术去解决问题。他们更愿意等到一项技术成熟，自身已经成为标准，并且已经具备了很好的支持体系才会购买。（5）滞后者会尽可能避免使用新技术。他们是最后采纳新发明的人，而且通常都是在别无选择的情况下才会采纳。

◆ Pinterest的创始人会去咖啡店里亲自让陌生人使用他们的产品，也会去Apple的体验商店把所有的浏览器首页都设置为Pinterest

◆ 蒂姆·库克不会在你买了笔记本电脑之后给你寄一张手写的卡片——他做不到，但你可以。这就是小公司的好处：你可以提供大公司实现不了的服务。一旦意识到现有的一些习惯做法并没有超出用户的预期体验，不妨好好想想，我们可以用多少手段去取悦用户，这是很有意思的。——Paul Graham, Y Combinator联合创始人，硅谷创业教父，《黑客与画家》作者

◆ 当你还是一家小型创业公司，仍然还在验证自己的点子时，做一些无法规模化的事情去获得早期的客户是你可以承担的方式。如果点子可行，后续可以通过自动化的方式，让这一过程变得更具扩展性；但如果点子不可行（大多数点子都是这样的结果），那么你也节省了大量的时间，因为你不需要为了错误的事情而做一大堆自动化工作

◆ 另外，这种方式可以让你直接接触业务的烦琐细节，你会成为领域的专家，而这一点在前面已经说过，它对于想出伟大的点子是至关重要的。

3.3 小结

◆ 用户界面就像讲笑话，如果非得解释清楚，就不那么好玩了。——Martin Leblanc, iconfinder创始人

4.1 数据

◆ 产品经理的工作就是要把两件简单的事情说清楚：·我们正在进行什么比赛？·我们怎么得分？把这两件事情做对，就可以不经意间聚集一批在技术、运维、质量、设计和市场推广上具备天赋的杰出人才，在同一个方向上聚力前行。没有这两点，无论做多少优化和执行管理，都拯救不了你。——Adam Nash, Wealthfont主席、CEO

4.2 营销

◆ 以下是创业公司最常见的4种营销渠道：·口口相传；·市场推广；·销售；·品牌化。

◆ 传播产品信息最强大的方法就是不自己去传播，而是让你的客户去传播

◆ 近来许多人都在谈论如何使用“病毒营销策略”，但现实中却没有这样的东西。在所有社交网络上出现的病毒式传播的博客文章或视频并不是一种市场推广策略，而是纯属好运

◆ 病毒式传播不仅仅是另一种形式的口口相传，如果你想突破我们前面讨论的实现途径（做出更好的产品、提供出色的客户服务），更进一步激发人们对你的产品进行口头宣传，需要的不是一种“病毒式的市场推广策略”，而是让产品进入一种病毒式循环。

◆ 同样，Apple最成功的广告之一 ——“不同凡想”（Think Different）并不是在介绍电脑或CPU速度，也不是在介绍Apple为什么比微软更出色，而是在回答“Apple是谁”以及“它代表什么”的问题。

第二部分 技术

◆ 好的技术栈的扩展要快于需要进行的维护。

◆ 谈到技术的作用，WhatsApp团队就是一个很好的例子。该团队基于Erlang搭建了一个技术栈，可以支持每秒7000万条Erlang消息、4500万用户，每天500亿条消息，每年7.2万亿条消息[插图]，而完成这一切的团队只有32个工程师

◆ 当然，这里讲WhatsApp的故事并不是说所有人都应该用Erlang。各种成功的创业公司都会基于他们所有可能想得到的技术，去实现他们的产品。这一章会帮助你解决“创业中可以使用什么样的技术栈”这一问题。首先，我会描绘如何选择最初的技术栈，如何随着时间推移使它逐步进化；接着，将把实现内部技术方案、购买商业软件和使用开源软件之间的权衡利弊呈现给大家；最后，我会深入谈谈创业公司最常遇到的3个技术决定的一些细节，即编程语言、服务器端框架和数据库

5.2 技术栈的进化

◆ 当我（离开Google）到了AdMob后，我心中的第一个冲动就是“噢，垃圾垃圾垃圾”。当然我没有说出口，因为作为领导者，学会的更重要的一课就是在开始说之前先闭上嘴巴去听。但是我脑子里想的是：“在Google我们是不会这样做的，在Google我们是不会这样做的，在Google我们是不会这样做的。”这句话在脑海里闪过了好多次之后，我才意识到这并不是在Google，我要解决的是不同的问题，面对的是不同的技术文化——这是很好的事情，真的很好

◆ 我们先从需要在很早就做出的一个决定开始：如何为创业公司选择初始的技术栈？我可以只用一句话来回答：熟悉什么就用什么

◆ 这句话源于我为这本书所做的访谈，我可以告诉你，每一家创业公司选择的只不过是创始团队最精通的技术。LinkedIn是用Java实现的，因为创始团队了解Java; GitHub的创始人全部都是Ruby开发者，所以他们也是用Ruby去实现网站的；Twitter主要用的是Rails，因为他们的早期员工中有许多人熟悉Rails。Foursquare开始时使用PHP，因为这是联合创始人Dennis Growley所了解的；Pinterest使用的是Python，因为创始团队对Python比较熟悉

◆ 学习一门新的技术、享受它承诺的所有理论上的好处可能很好玩，但在创业早期，我们的目标是认识到用户需要什么，其他任何花时间的事情都是浪费。在早期，产品的用户和代码都不多，所以可扩展性并不是太大的挑战，我们要做的就是尽可能快地进行迭代

◆ 如果你的创业公司足以成功地生存到“下一周”，也许你可以让技术栈有所进化，使之满足新的需求。例如，Twitter开始时用的都是Ruby on Rails，但发展起来之后，就不得不迁移到Scala和JVM上；HubSpot从．NET和SQLServer迁移到JVM和MySQL、Hadoop及HBase; Coursera现在从PHP迁移到了Scala; LinkedIn在它的发展历史中已经尝试了十多种技术，包括Java Servlets、Groovy on Rails、JRuby on Sinatra、Java和SpringMVC、JavaScript和Node.js，以及Scala和Play Framework

◆ 最初选择的技术并不是关键，最初的决定在最后看来一定是错的，唯一的问题是它会错多久。关键在于，你要在遇到拐点时有壮士断腕的勇气，而不是为了存活而一层一层地给它贴上创可贴。遵循这样的准则极其重要。从目前来看，这比紧跟潮流、为了做出初始的最佳技术决定而进行无穷无尽的设计分析要更为重要。我们应该做的是，确保把自己和环境锻造成能够适应各种变化，能够知道什么时候是重建的合适时机。——Kevin Scott, LinkedIn高级副总裁、Admob副总裁、Google主管

5.3 内部实现、购买商业产品，还是使用开源产品

◆ 一个残忍的事实是：当你的关键业务过程运行在内部情况不清楚（更别提修改）的不透明代码上时，你就失去了对业务的控制。你对供应商的需要超过了供应商对你的需要——因为这一巨大的不平衡，你只能付钱、付钱、再付钱。——Eric S. Raymond, 《大教堂与集市》

◆ 简而言之，每当使用商业产品时，就是将公司的一部分投注在无法控制的第三方身上

◆ 如果某些技术自己实现起来非常复杂、很容易出错、要花大量时间，但开源和商业领域已经有很好的方案，那么作为创业公司，就永远不要自己去实现这些技术。下面列出了部分这样的技术

◆ ·安全：加密、密码存储、信用卡存储。·Web技术：HTTP服务器、服务器端和客户端框架。·数据系统：数据库、NoSQL存储、缓存、消息队列。·软件分发：版本控制、构建系统、自动化部署。·计算机科学：基本数据结果（映射、列表、集）、排序算法。·处理通用数据格式的库：XML、HTML、CSV、JSON、URLs。·实用库：日期/时间操作、字符串操作、日志记录。·操作系统。·编程语言。

◆ 如果你要从头开始实现上述系统中的任何一个，只能有两个原因：一是以学习为目的的个人项目，二是你的创业公司对其中的某项技术有极其独特的需求

◆ Google就是一个很明显的“非自主发明不可”的栈，它所有的一切都是内部编写出来的。在Google的时候，我想可能除了gcc之外，我没用过任何一种开源工具或库。部分原因是Google领先行业内其他所有公司5年或5年以上。Google所做的东西，就是像MapReduce（使用无数低成本的商业硬件去运行分布式系统）这样的产品，他们基本上都是在发明和普及很多这样的产品。这些产品现在全都成了行业标准，但是大部分在Google之前并不存在。我觉得Goolge就是因为比其他公司超前了许多，所以不得不去实现，这样的境况也许又成为了一种自我增强，因为我们已经形成也适应了非自主发明不可的文化。——Brain Larson, Google和Twitter的软件工程师

◆ [插图]图5-1：内部实现、购买商业产品或使用开源产品

5.4 选择编程语言

◆ 每一种编程语言对于如何解决问题都有不同的哲学。我们可以把编程语言的范式当作是该语言的词汇和语法，决定了你如何说和可以怎么说。目前很少有确切的证据表明某种范式优于其他范式[插图]，但某些范式相比其他范式可以更方便地表达一些想法

◆ Ruby支持线程，但它有全局解释器锁（Global Interpreter Lock, GIL），这意味着一次只能执行一个线程。此外，大多数主流的Ruby库执行的是同步I/O，在等待磁盘读取或网络调用返回的时候会阻塞线程。这导致了Ruby并不是处理大量并发的高效语言

◆ 当你选择一门语言时，面对的不仅仅是技术上的权衡取舍，而是一个社区。就像选择一间酒吧一样，没错，你去酒吧是为了品尝美酒，但那还不是最重要的——酒吧更是人们休闲和聊天的地方。这和选择计算机语言的道理是一样的，一门语言随着时间的推移会建立起社区，不仅仅是人，还包括软件方面的产物：工具、库等。这就是为什么有一些语言理论上比其他语言要出色，实际却不如其他语言的原因之一——它们还没有建立起健全的社区。——Joschua Bloch, Sun公司分布式工程师、Google首席Java架构师

◆ 我们可以应用三个过滤条件快速缩短这一列表：适用问题、编程范式和性能需求

◆ 例如，一家做计算机视觉和机器学习系统的创业公司，应该根据适用问题把这份列表限制为三门语言：C++、Java和Python。如果该创业公司更偏爱静态类型，就可以把Python从列表中剔除。最后，如果他们实现的是高性能的实时系统，就不能使用垃圾回收，这样就只剩下了C++

◆ 一家做Web应用程序的创业公司，最有可能觉得Java、JavaScript、PHP、Python、Ruby和Scala最适合解决他们的问题。如果该团队更喜欢动态类型，可能会从清单中去掉Java和Scala。如果他们中有一小部分人已经熟悉Python，并发现几个Django插件可以节省许多时间，Python将成为他们的最佳选择

5.5 选择服务器端框架

◆ 库和框架之间的区别是什么呢？通常的答案就是控制反转：我们把库插入到代码中并调用它们，反之我们把代码插入到框架中并让它们去调用你

◆ 这也称为好莱坞原则：不要给我们打电话，我们会打电话给你

◆ 如果你在开发Web服务，除非你调用socket.accept并编写自己的HTTP解析代码，否则总是应该把代码插入到某种调用你的框架中

◆ 这种框架也许是像Ruby on Rails这样的全栈框架，可以把控制器（controller）插入到处理请求中；或者是更加精简的框架，比如原始的HTTP服务器，可以插入函数去处理HTTP消息。无论哪种情况，你都离不开框架。所以，选择库还是框架通常都不是问题，问题是选择最精简的框架还是选择全栈框架

◆ 全栈框架，比如Ruby on Rails，就是一种为大多数常见任务内置提供了默认解决方案的框架，像路由、数据建模、视图渲染、国际化、配置和测试。最精简的框架，比如Sinatra，只为你提供简单的基本功能——也许只有HTTP路由，再内置一点其他功能，你自己想办法处理各种常见任务

◆ 任何库复杂到一定的程度之后，都会包含一个临时的、不合规范的、充满程序错误的、运行速度很慢的、只有一半功能的全栈Web框架，这是向格林斯潘的编程第十定律致敬。该定律告诉我们，任何C或Fortran程序复杂到一定程度之后，都会包含一个临时开发的、不合规范的、充满程序错误的、运行速度很慢的、只有一半功能的Common Lisp实现

◆ 全栈框架包含所有内置功能只有一个原因：现实中的大部分应用程序都需要它们。即便你现在并不太用得上这些功能，框架中内置这些功能增加的成本也不多，所以因为某种程度上“感觉繁重”就舍弃不用，未免有点目光短浅。当然，并不是每一个内置的解决方案都能满足你的需求，所以要寻找80%～90%的默认方案都能满足要求的框架。一旦它不能满足需要，你可以立马用定制的库去代替

◆ 大多数Web框架都提供了渲染HTML的模板库。当我们评估模板库的时候，主要需考虑内置的视图辅助方法、服务器端与客户端的对比、有逻辑和无逻辑模板的对比。

◆ 许多Web框架，比如Ruby on Rails、Servlets和Django，会为每一个请求分配一个线程（或进程），在等待I/O调用的时候（比如等待数据库或远程Web服务的响应）阻塞该线程。

◆ 如果线程太少，很容易出现所有线程都被占用而处于等待I/O的状态，阻止线程对任何新请求的处理，即便大部分线程仅仅是在空等待；如果线程太多，就会引发额外的内存使用和上下文切换导致的巨大开销。所以，确定合适的线程数量也是很困难的，因为它取决于服务器的负载和下游依赖项的延迟情况，而这一切都是经常处于变化中的

◆ 处理I/O更高效的方式是使用基于非阻塞I/O实现的Web服务端，比如Node.js或者Netty。

◆ 利用这种方式，在等待I/O完成的时候，我们并不是将线程阻塞，而是注册一个回调（或者承诺），该线程就可以继续处理其他请求。当回调被触发时，线程可以将请求唤起，完成对它的处理。因为I/O处理的时间会比其他进程内的处理时间长好几个量级，所以异步处理I/O的方式使我们对服务器资源的利用更加高效。通常来说，非阻塞服务器的每个CPU核心只需要一个线程（或进程），并且对下游的延迟情况也不那么敏感

◆ 和所有性能问题一样，找到答案的唯一方式就是进行性能测试和测量。读者可以查看TechEmpower Web框架基准测试作为入门，或者阅读第7章了解有关性能测量的内容。

◆ 跨站点请求伪造（Cross-Site Request Forgery, CSRF）攻击是指恶意网站让用户在受信任的网站上执行有害的动作。

◆ 例如，假设你访问win-an-ipad.com网站，该网站让你在表单中输入一些数据并提交，这样你就有机会赢得一部iPad。但你不知道的是这个表单实际上被提交到了Amazon，这是一个你信任并且已经登录的网站。如果Amazon没有CSRF保护，攻击者就可以精心制作出符合要求的表单，Amazon会将提交的表单解释为你在购买东西，因为浏览器会将你的Amazon cookies和提交的内容一起发送出去

◆ 为了防范CSRF攻击，Web框架应该具有为每位用户生成短暂的随机令牌的机制，将其存放在cookie中，如果body中的令牌和cookie中的令牌不匹配，则拒绝提交表单。这样在渲染自己网站上的合法表单时，我们就可以轻松地将令牌作为隐藏的表单字段，把它包含在表单中。当攻击者尝试渲染网站上的恶意表单时，他们无法读取你的cookies，也就无法猜测到正确的令牌值

◆ 下面列出了一些截至2015年最流行和成熟的框架，按照编程语言划分并根据首字母进行了排序，内容主要来源于HotFrameworks和我自己的经验。·C#:.NET。·Clojure:Ring、Compojure、Hoplon。·Go:Revel、Gorilla。·Groovy:Grails。·Haskell:Snap、Happstack、Scotty。·Java:Spring、Play Famework、DropWizard、JSF、Struts。·JavaScript:express.js、sails.js、derby.js、geddy.js、koa、kraken.js、meteor。·Perl:Mojolicious、Catalyst、Dancer。·PHP:Laravel、Phalcon、Symfony、CakePHP、Yii、Zend。·Pyhton:Django、Flask。·Ruby:Ruby on Rails、Sinatra。·Scala:Play Framework、Spray。

◆ 应用三个过滤条件，可以快速删减这个列表，即编程语言、适用问题和可扩展性

第6章 整洁的代码

◆ 编程是一种让他人了解你想让电脑做什么的艺术。——Donald Knuth

◆ 作为一名程序员，只有不到50%的工作时间是花在编程任务上的。编程的时间里面，阅读代码和编写代码的时间比大大超过了10∶1，而实际花在编写代码的极少部分的时间中，80%以上的时间又是在维护代码，即修改或修复已有的代码。如果一天工作8小时，能有5分钟花在编写新代码上就已经不错了。结果就是，程序员的工作并不是在编写代码，而是在理解代码。

8.3 构建

◆ 理想状态就是每一次提交都是完全实现了某一个单一目的、大小合理的单元

◆ 开发人员同时完全隔离工作数周或数月，到了最后一分钟又尝试将所有的代码合并到一起。这个过程就是所谓的后期集成，就像我们在本章开头看到的LinkedIn的故事一样，通常都会导致灾难

◆ 更好的方法就是第二种选择所描述的，是持续集成，所有开发人员定期（每天或者每天多次）将代码合并到一起，这一过程可以尽早暴露设计中的问题，避免在错误的方向上走得太远，我们也可以增量式地改进设

9.3 组织设计

◆ [插图]图9-2：不同公司的组织结

9.6 办公室

◆ 分心是专注工作的敌人。对于基本的脑力劳动（比如算法）来说，只要一小点办公室噪声都会产生影响。编程甚至需要更加集中的注意力，你必须把问题加载到大脑中，就像用纸牌搭房子，需要花时间并且耗费大量的脑力，而且一丁点儿干扰都可能把整个屋子弄倒，让你不得不从头开始

◆ [插图]图9-7：这就是不要打断程序员工作的

◆ 研究表明，一名程序员平均要花10～15分钟才能从干扰中恢复过来，重新开始编写代码。一个小时被干扰4次，就足以让你的生产效率下降到零

◆ 这就是为什么搞开发的人为了回答你的问题，眼睛从屏幕离开时会给你一个如此不友善的眼神。因为他们脑子里的纸牌屋已经摇摇欲坠了。仅仅因为存在会被打断的可能性，就会让这些开发人员不敢开始困难的项目。这也是为什么他们喜欢在深夜工作的原因，也是他们几乎不可能在隔间里写出出色软件的原因（除非在深夜）。——Paul Graham, Y Combinator联合创始人，硅谷创业教父，《黑客与画家》作者

◆ 也许你就是这样的人（我知道我曾经就是）。你甚至会对自己长时间的工作感到自豪，认为自己是个英雄。但是更长的时间——每周超过50个小时，并不会提高工作效率。这一切只会增加压力、损害健康、让你犯下粗心的错误，最终情绪沮丧、逃离工作。换句话说，需要英雄事迹就是一种失败的信号，意味着一些事情严重缺乏规划和管理

◆ 不需要英雄的环境好过一个团队都是英雄的环境。——Ernie Miller, Nvisium技术主管

9.8 沟通

◆ 健康的公司文化鼓励员工去分享坏的消息。可以自由、公开讨论其问题的公司也可以快速地解决这些问题，而掩盖问题的公司则会打击员工参与的积极性。所以CEO的做法应当是：营造一种文化，奖励（而非惩罚）人们将问题公开，使得问题得以解决。——Ben Horowitz, 《创业维艰

9.10 小结

◆ 《基业长青》一书对一项6年研究项目的结果进行了概括，该项目致力于研究成功打造一家“有远见的公司”的必要条件——被认为是所在行业中最出色的公司之一。这样的公司历经多年，产品和领导也经受住了考验，对世界产生了持续的影响，比如迪士尼、IBM、波音和通用电气

◆ 《基业长青》中有一个关键发现，就是有远见的公司的领导会关注创立伟大的组织而不是伟大的产品——那样的公司只是“制作钟表的”，而不是“时代的讲述者”。他们最伟大的产物并不是特定的想法或产品，而是公司本身及其代表的东西

10.1 寻找创业公司的工作

◆ 我曾经遇到过一个人，他是一家银行的软件工程师（不是JP摩根或者其他顶级的银行，只是中等的、相对不那么知名的区域银行），在两三年前给我发了电子邮件，说到“我想加入一家创业公司，应该做些什么呢”。我的回答是，出去参加两三次黑客马拉松，花几个星期去做项目。你可以把你的简历水平从B或C变成至少B+或A-，这一点在几个月内就可以做到，然后再去硅谷，申请公司职位就可以了，因为湾区或任何科技中心的机会要比其他城市的机会多得多。他在一年后发邮件给我，告诉我他已经成了Uber早期的工程师，赚到了许多钱，现在的情况好了很多。——Gayle Laakmann McDowell, CareerCup创始人、CEO

◆ 读者不妨访问http://www.hello-startup.net/resources/jobs/网站找找你周边的编码竞赛

◆ 如果想让社区关注你，最好的方法就是为社区做贡献：做演讲、写博客、将代码开源、处理邮件列表、在Stack Overflow上回答问题、在IRC上聊天。只要我参见会议或聚会小组，离开时便可以获得5～10个新的联系人；只要我在会议或聚会小组上做展示，离开时便可以获得几十个新的联系人。读

◆ 如果不能通过人脉找到工作，那么退而求其次，看看能不能让工作找到你。在过去的5年，我已经收到大约1300封电子邮件，这些邮件来自创业公司的创始人、招聘经理和招聘人员。我的收件箱在几乎每个工作日都会收到至少一个工作机会，我不再需要申请工作——而是工作向我申请。

◆ 几乎每一名程序员都可以在恰当的地方创建一个网络身份，从而实现类似的事情。如果想让公司找到你，你的名字应该出现在它们会去的地方

11.2 招聘什么人

◆ 创业的低谷非常之深，几乎没有人可以独自承受这一切。如果有多名创始人，团队精神会使他们以看似违背能量守恒定律的方式凝聚在一起。每个人都认为“我不能让我的朋友失望”，这是人性中最强大的力量之一，在仅有一名创始人的情况下，他将失去这一力量。——Paul Graham, Y Combinator联合创始人，硅谷创业教父，《黑客与画家》作者

◆ 两个创始人通常是通往成功的最好途径。你可以平均分配工作和股权，也没有政治操作的空间。三个创始人也没有问题：只是在职责划分上会更困难一些，但总可以通过投票决定。一旦超过了三人，事情会变得越来越不稳定，做出决定也变得更加困难，职责和股权的分配也更难处理，更有可能出现政治问题和内耗

◆ 开始的时候，我只会聘请全栈的人，因为不想有人说：“这不是我的工作。”在公司最开始的阶段，每个人头上都要顶着好多帽子。只有到了稍后期，我才会去招聘专才。——Julia Grace, Weddinglovely联合创始人、Tindie CTO

◆ 这里有一个重要的提醒：专才的反面并非是通才。不是任何方面的专家并不意味着你就擅长各个方面。真正的通才是那些多面手的人，你把一些新东西放在他们面前，他们就会把它带走并弄清楚它是如何工作的。他们拥有永不满足的好奇心，愿意对所有东西都稍做尝试。但你要是看看他们的简历，就会看到大量行业的经历（例如旅游、医药、社交网络、消费者、部署自动化、编程语言设计）以及职业角色（例如开发人员、技术主管、产品经理、设计师）

◆ 如果你听到一个开发人员说“噢，不，我不是搞前端的”，或者因下一个项目不得不学习新的编程语言时有所畏缩，这样的人可能就不是通才

◆ 真正的通才喜欢学习新东西，不管问题的领域是什么，也不管他们是否已有相关经验

◆ 当你需要调优数据库查询、建立复制或共享表格，也许就是时候去招聘一个专职DBA了；当你需要管理数以千计的服务器、把代码部署到多个数据中心、建立24×7的网站监控，也许就是时候去招募一个专职发布工程师了；当你的网站规模大到经常遭受黑客和垃圾邮件的攻击，也许就是时候招募一支专职安全团队了。但要提防招聘那些只擅长一种技能而别无他长的人。相反，我们需要T型的人，这一点已经在2.1.1节讨论过

◆ 我们并不是要编写更多的代码，而是要编写正确的代码。10倍能力的程序员实际上是10倍能力的决策制定者

◆ 你是想要10个平均水平的科学家还是1个牛顿呢？10个普通的科学家想不出运动定律、引力理论或者微积分原理，但1个牛顿却可以做到。你是想让埃隆·马斯克去运营公司，还是想把钥匙交给10个普通的执行官？10个普通的执行官想不出Paypal、电动汽车、可回收火箭和超级高铁，但1个埃隆·马斯克却可以做到

◆ 超级明星程序员，就像超级明星运动员，是格外稀少的。如果你尝试根据只招聘“摇滚明星”的原则去制订自己的招聘策略，或者更糟的情况是，如果你的公司招摇过市，好像已经是一群“摇滚明星”，你就永远无法发展你的团队

◆ 开发人员在能力上也许会有巨大的差异，但是这一点不能掩盖下面这三个关键的事实：（1）开发人员的表现会根据不同的任务而有所不同；（2）开发人员可以逐步变得更好；（3）大多数软件都是由团队而不是由个人开发的。

◆ 第一个事实意味一个公司中10倍能力的开发人员在另一家公司中可能只是1倍能力甚至0.1倍能力的开发人员。文化、激情和使命才是至关重要的（阅读第9章了解更多信息）。

◆ 只有聪明才智是不够的，也许你和这样的聪明程序员共事过，他可以滔滔不绝地说上几个小时，介绍一种技术与另一种技术相比，在理论上有什么好处，他会花许多时间去撰写设计文档、架构图和UML图，但是从来没有实际给出过任何代码。我们有时候称他们为设计师，有时候又称他们为教授。不管怎么样，创业公司需要的不仅仅是聪明的人，还需要能够把事情做好的人。我们需要的是可以权衡取舍、可以利用不完美的信息做决定、能够理解完成比完美更好的人

◆ 注意，我们要寻找的这种“聪明”和IQ或者漂亮的学历并没有多大关系，更多的是要有清晰的思维和解决问题的能力

◆ 你还要花大量时间和你所招聘的人在一起，在小型创业公司中更是如此。设想你要每天都和这个人一起吃午饭，要他们去评审你的代码，要花时间去了解他们或者从他们身上学习东西，当网站出了问题他们会在凌晨3点打电话给你。虽然你没必要希望招聘到能够变成朋友的人，但你肯定要避免招聘到你无法相处的人

◆ 在许多公司中，这种品格有一个好听的名字：无混蛋规则。这是一条很好的规则，但不是“混蛋”还不够，你真正需要的是找到很好地与你的公司文化相契合的人（阅读第9章，了解有关创业文化的深入讨论）

11.3 寻找出色的人选

◆ 假设你是一个有两名合伙人的团队，想要招聘12名技术人员。你认为完成这一任务要花多少时间？答案是：大约990小时，或者在一整年里每周花大概20小时去招聘。

12.2 学习的技巧

◆ 我已经发现了三种让我的研究时间变得更有效率的方法。第一，设立具体的、可测量的目标。例如，我为2015年设定的目标是阅读30本书（我用Goodreads来记录我的进度）。

◆ 我还有一个目标，就是每年至少学一种主要的新技术，比如一种新的编程语言或数据库，我发现“七周七种”系列图书，比如《七周七语言》[插图]《七周七数据库》[插图]和《七周七并发模型》[插图]，都是实现这一目标很好的方法，因为这些书会向你介绍各种各样的技术，还会重点强调不同的编程范式，

-- 来自微信读书