成为“摇滚明星”：软件曾经是个人才／创意行业

　　编者按：本文讨论了软件行业的问题，指出应用软件已经不再是创意和才能的游戏，而是逐渐被“商品化”了，一切都要按照剧本走了。这种方式既无趣又缺乏动力，更多是基于风险管理而不是结果最大化。这导致了软件业的很多人感到非常沮丧。文章提出，需要重新考虑这种做法，并重视培养有创意和有才能的团队。文章来自编译。

　　《黑客都跑去哪儿了？》那篇文章背后都是谁在煽风点火？就我所知，其背后最大的始作俑者之一是 Kellan ，他写了《软件及其不满》系列。这些都是很好的文章，旨在回答“为什么现在人人都对软件感到那么痛苦？”这个问题。

　　我很喜欢这个话题，这些文章讲到了各种怨气，但我感觉并没有讲清楚我观察到的其背后的总体叙事：应用软件不再是一场发挥“创意”和“才能”的游戏，现在已变成一滩“商品化的烂泥”，有手册知道如何去制作。这本手册描述的游戏 a) 对于大多数玩家来说很无趣或没有激励作用，b) 基于风险管理（恐惧）而不是结果最大化（希望），以及 c)……但实际上似乎还是没起作用？可如果你不按照手册做，每个人都会对你大喊大叫，说你不成熟或不认真？

　　劳动力/招聘市场总是赶不上形势，因此在一段时间内，薪酬和叙述讲的都是创意人员/黑客的，但衡量工作和结果却很保守和面向管理的。软件是按照泰勒·斯威夫特的方式定价的，但却是由“未获认可的工作室音乐家”开发的。

　　对于很多从事软件工作的人来说，这种情况非常令人沮丧，但我却特别感兴趣：当我们反应过度并太过循规蹈矩时，就会阻止任何的“泰勒·斯威夫特”出头，因为我们决定采用平庸的工具，并让团队“最低标准”化。要想找回“那种神奇感觉”，你得努力摸到天花板，让员工发挥最大潜力，而不是将他们扁平化，尽管要做到这些也许很令人生畏。

　　本文的目的是阐述我所谓的“创意”/“人才”行业的含义，文章认为背离这种模式会让软件对每个人来说都变得更加痛苦，也许我们需要重新考虑一下代表这一举措的操作手册，至少做出部分调整。

　　2009 年的时候，我买了这本书，因为只要看看代码库，就会发现它是有风格的。你得有某种“代码手写能力”。但现在我们有black（python自动格式化工具）和gofmt（go自动格式化工具）。

　　在这些行业中你经常看到这样的事情：球探和制片人去寻找真正的人才的时候会运用他们的“直觉”，因为规规矩矩地审视，作用并不明显。这些行业是……很多彩的。娱乐业就是一个例子：如果你是 1990 年代的一位音乐高管，想要靠垃圾摇滚赚钱，你可以试着与专业音乐家合作创建一支新的垃圾摇滚乐队，或者也可以让星探到车库去找些年轻人。

　　其中一种做法绝对是更好的选择：做出成功的垃圾摇滚没有任何公式可以参照；一些乐队就是有那种魔力，可以与一起购买 CD 的不满的白人青少年产生共鸣，而其他一些乐队确实演奏乐器的技巧很华丽，唱得也不错，但就是缺少这种魔力，得不到青少年的认同。因此，就像捕虾船一样，最成功的垃圾摇滚乐队（就像娱乐业中大多数其他洞悉青年文化的网红一样）并不是圈养出来的，而是在野生捕获的。

　　Reply-All 这个播客其中最著名的一集里面，有一位音乐家与一位聆听了他样片的主流唱片公司高管的对话。从中我们可以思考不同的人的生活方式和价值观是怎样的，可以思考一下“工作”对他们来说是什么样子的，以及这两个人相遇并成为合作者是多么有趣：

　　我想说的是：软件更是如此。2009 年，你以本科生的身份飞到旧金山参加 Facebook 面试，入住酒店，享受免费食物，这一切都是因为你会编程吗？尤其是如果过去两年你一直在图书馆默默折腾自己的业余项目的话，你会感觉这很酷，但同时你也会感到茫然和困惑：为什么会有这么一台看不见的机器，只是为了看看你是不是拥有他们所需要的魔力而愿意花那么多的钱？

　　人才/创意产业的要素是：

　　必须非常有价值，就像职业运动员、音乐家、电影明星一样。企业要想取得巨大成功，需要对想招进来的人来说也能取得巨大成功。

　　想“综合”地复制成功肯定是很难或不可能的。我们甚至有一个旨在培养流行歌星的节目（《美国偶像》），虽然很多参赛者多多少少都从事过音乐这一行，但这个节目其实后来只制造出一位流行歌星（凯莉·克拉克森，第一届的获胜者）。像这样的行业在“谁拥有魅力”这件事上必定有一定程度的神秘感。

　　这种魅力……其实很重要。我认为技术圈的问题出在：要有一个实际的力量倍增器才能拥有这种难以言表的才能。肯德里克·拉马尔（Kendrick Lamar）之所以是肯德里克·拉马尔，需要真正创造出肯德里克·拉马尔规模的成果。我认为技术圈确实让我们自己相信，如果我们能像 Paul Graham 那样写 Lisp，作为聪明人的我们就能致富，但事实证明，说服自己是一个创新的技术天才比真正成为一个创新的技术天才要容易得多。实际上靠投资于天才黑客而获利的公司非常非常少：对于大多数公司来说，阻力较小的途径是利用“科技公司”的品牌和光环，把开发作为成本中心，然后去玩金融。

　　《why's (poignant) Guide to Ruby》

　　还记得我们写过像这样的编程语言书籍吗？对于年轻人来说，这是来自 why's poignant 的 Ruby 指南。另外，还记得当一位奇怪的丹麦赛车爱好者用 1995 年的语言编写了一个框架时，大家......却很喜欢吗？

　　因为虽然《软件及其不满》中的分析没有任何问题，但我认为，对于接受“软件是创意行业”的叙事（并围绕着这种叙事构建现实）的团队来说，里面提到的问题大部分都得到了缓解。话虽如此，他和我可能永远不会在这个问题上达成一致，因为他或多或少发明了“选择无聊技术”，而我提倡的大部分内容是打破手册、拥抱叙事并变得有趣。

　　他在文章中提出了四个要点：

　　软件开发复杂性的爆炸式增长

　　科技人才变得更加昂贵

　　成功变得比以往任何时候都更加难以捉摸，初创企业“失去了那种神奇的感觉”

　　对工作环境不断变化的期望产生的冲突

　　我们来逐一审视这些问题。如果你有“创意产业”的心态，就能摆脱其中最糟糕的情况。

　　第一：少招点人。如果不是感觉极度受限的话，就不要招人。在大约 5 到 7 年的时间里，工程师开始沾沾自喜地说“最好是一行代码都不写！每一行都很贵，都必须维护”，虽然这绝对是真的，但我希望你把招聘一位新员工给组织带来的运营成本至少想象成跟一条 20 万美元的线路服务一样昂贵。

　　WhatsApp 当初被 Facebook 收购时，他们只有有 35 名工程师。他们之所以能够做到这一点，部分是因为他们没有“按照手册”做，虽然你可能不会那么极端，但如果把软件业当作创意产业看的话：你觉得增加 400 名编剧，SNL 就会有所改善吗？如果 HBO 给《权力的游戏》增加 15 名制片人又会怎样？

　　团队是一种不可变的数据结构：一旦改变了团队，你就会得到一支新的团队。太快添加太多人员，会增加公司的沟通成本。如果人们被介绍到一家缺乏足够的经验丰富的导师的公司，而公司又没有建立起自己的文化和愿景的话，他们就会添加流程，生成文档，因为这感觉好像工作很高效。但你的客户不关心这些。

　　我想以池塘的生态体系为例：想象里面会有乌龟、鱼、细菌以及藻类。这就是你们公司的文化。如果你把相当于其总量 5% 的来自其他池塘（细菌、鱼、藻类不一样）的水加入到该池塘里，几周后得到的池塘几乎与原先的池塘是一样的，不过是水量更多罢了。但如果你往里面加入 40% 的新水，新池塘的动物群可能就会胜出，最终原先那个池塘可能会变得面目全非。

　　招聘要谨慎，但更重要的是：尽可能慢一点招人。额外的好处是，这对要招什么样的人也适用。

　　（我认识到，我们之所以要招聘这么多的员工，原因之一是来自投资者的压力。如果你是一家公司的领导层，你的日常数据看板会有手头现金方面的数据，投资者不想要回现金：他们想要的是“现金减少，股价上涨”，你需要在下一次董事会会议之前实现这一目标。在利率为零的时代，实现这个目标的方法之一就是雇用昂贵的工程师。）

　　你还可以用打破常规剧本来“假装我们属于创意产业”：

　　考虑将服务器托管在同一机房内（colocating servers）而不是放在云端。Squarespace 做到了，Twitter 做到了，Basecamp 做到了，Stack Exchange 做到了。这不仅是可能的，而且通常要便宜得多。

　　见鬼，刚开始时甚至可以考虑“pets, not cattle”模式（编者注：在云计算和 Web 服务领域，这句话用来区分两种不同的服务器管理理念。cattle 意味着将服务器当作无差别、可替换的量产品。pets 意味着将每台服务器当作独一无二、不可替代的个体）。不要做出 Heroku 与你自己产品的劣质版，这样后面会很麻烦。

　　考虑有状态的部署，至少把它作为无状态之上的另一层。如果你有一个基于 Docker 的工作流，可以通过 git 克隆新的基础镜像，不妨考虑托管一个持久的构建服务器，用 git 去 pull。Fred Hebert 就讲过自己工作过的公司的案例，他们以干掉有状态部署的名义，从 BEAM 迁移到 Go + Docker（遵循手册，选择无聊）， 从而彻底失去了功能和灵活性。

　　上面提到的每一点都可以独立成文，里面涉及到大量注意事项与支持证据。但我觉得现在已经说得够多的了，所以剩下的我会快速略过。

　　我讨厌复杂这个词。作为一个行业，我们对复杂缺乏共同的定义，复杂通常意味着“我不喜欢的狗屎”。幸运的是，Kellan 给出了稍微精确一点的信息：

　　在系统思维和软件当中，“复杂”都是个技术术语。它指的是系统不同部分以及它们之间的连接的数量。复杂系统的特点是非线性、随机性、涌现性以及意外性。在开发软件时，复杂性是沟通和协调成本高于所有其他成本的原因所在。

　　你有没有注意到上一点的示例也删除了事物之间的联系？人，整个基础设施栈，以及当你想吃个蛋糕时就得建造一整家面包店并且还得做好维护的想法。这些都没了！

　　但我们还可以继续。扔掉手册，来点创意：

　　是不是每家公司都需要一支完整的全职员工团队来支持 React 客户端，这样的客户端需要服务器端渲染（SSR），需要额外的基础设施支持“水合作用”+ 比整个 Flash Runtime 运行时还要复杂的构建系统以及 node_modules 文件夹内置的设置？不妨考虑用 htmx、服务器端模板或 LiveView 替代一下？

　　你真的需要微服务吗？Kubernetes 呢？Terraform 呢？不妨再假装你回到 2011 年，部署 JAR 或二进制文件，保留并维护一个单体系统。 Dropbox、YouTube、Instagram、Facebook Blue App、Shopify……（大部分）都是单体系统，（大部分）都诞生于悲惨时代之前。

　　你可以使用扩展性优于 Ruby、Python 或 Node 的技术吗？这方面我可以再展开写写，但是只要你跟任何要处理在这些技术栈的庞大代码库的工程师交谈，他们都会告诉你会发生一些在 JVM 不会出现的坏事情。我在另一篇博客文章中讲到：“你创建了一个针对创始工程师进行优化的环境，他们是可以前 7 个月内快速开发出某些东西来，但代价是此后会反复出现一系列的障碍，让后面的工程师在未来 7 年内为此付出代价”。

　　上表说明Erlang 可以很好地替代 4-5 种技术，而下表中说明 LiveView 可以替代其他 4-5 种技术。我之所以如此看好 BEAM 和 LiveView ，部分是因为它们干掉了如此多的链接和连接。掌握它们需要一条学习曲线，但如果你掌握好的话，就会有一个非常强大的工具。

　　我上面的所有建议都能从根本上降低开发软件的成本，这有望带来更大的成功。

　　此外，你招收到的那些勇于打破常规的人才，既更容易受激励，也能激励团队的其他人。Ramp 首席执行官 Eric Glyman 最喜欢的一篇文章是《Amp it Up!》，里面他谈到了很多想法，但核心是这个：保持斗志旺盛！ 同样是 50 人的团队，如果里面有位工程师负责整个产品和技术栈（WhatsApp 那种风格）的话，其表现要比只负责 3 个页面的 React 开发者要好（而且也会更快乐）。

　　技术不会成为你的企业获胜的原因，但技术可以帮助创造出高能量、高动力的环境，这可以大大增加你的机会。

　　我会用一个我没有答案的问题作为结束：应用软件行业对创造力的要求是不是不可简化？我的意思是：有没有可能产生一套具有成本效益的“既定解决方案”？

　　我想说的是，有些行业没法可靠地成为具有成本效益的污泥工厂：有些人才你得野生捕获，并且没法可靠且综合地生产出“产品”。我举了垃圾音乐的例子，但其实我更喜欢以 HBO、迪士尼和 Netflix 的内容大战为例。

　　看吧，HBO 和迪士尼几十年来一直都是内容之王。他们拥有制作出大家喜爱的优质内容的渠道。他们知道你必须付钱给洛杉矶一群怪得不能再怪的怪人，并根据直觉下奇怪的赌注。这里有个关于 HBO 的故事，看看他们是如何差点与这十年来最成功的电视节目失之交臂的，因为制片人差点就被他们解雇了：

　　卡罗琳·施特劳斯（Carolyn Strauss）就是其中之一。尽管为 HBO 制作了一部又一部的热门作品，但她还是在 2008 年被扫地出门。据她讲述，这是因为她错过了一部电视剧，也就是《广告狂人》。结果，几个月后，她被解雇了。在即将离开的时候，她说，“我正在制作一部电视剧，我想继续做下去。这是一部关于龙的作品，你们看可以吗？”结果对方同意了。然后，卡罗琳·施特劳斯成为了 HBO 有史以来最成功的电视剧《权力的游戏》的顶级制片人之一。

　　这些都是非常人性化的过程。Netflix 属于新进入者 ，这家公司以技术为先，因此当他们进军原创节目市场时，他们打算靠数据来杀出一条血路。 “数据显示，新订户在两季后就会减少，节目将只有两季”（额外好处，这样剥削起洛杉矶的娱乐工作者会更容易）。

　　他们正在输掉赌注。事实证明，大家对漫威电影、《安多》（Andor）以及《彩排》（The Rehearsal）的渴望无比高企，远胜一部投资 2 亿美元、由热门明星主演但无人观看的电影，或威尔·史密斯那种笨拙的种族主义寓言电影。

　　（有趣的是，我有一个朋友在《冰雪奇缘》上映期间曾在迪士尼动画公司工作，她毫不客气地说他们当中有很多人都相信这将是一部失败作品——这场游戏你是没法预测成功的。）

　　所以有些行业不会产生“污泥”。总有一天，人类必须成为人类。我想知道软件在多大程度上属于这样？可能比娱乐业还要更甚，因为相对而言，艺人从娱乐业转型到流媒体服务，比从流媒体服务进入娱乐业更容易。但我认为这一情况的确定性并不像我们的行业“手册”所宣传的那么强。

　　译者：boxi。

　　举报/反馈