自诩理性的程序员们，其实比谁都更需要这本“防忽悠指南”

编者按：这是一个信息爆炸的时代，假新闻、选择性事实、钓鱼横行，任何人都要需要擦亮眼睛，用批判性的眼光区分什么是事实、什么是观点，哪些观点才有合理性。这一点同样适用于工程师。工程师整天想着如何防止自己的系统被“利用”，但是螳螂捕蝉，黄雀在后。他们却很少想过如何防止自己被“利用”——技术提供商、投资者、媒体提供给工程师的信息往往带有自己的目的，或者是忽悠你选择它的技术，或者是想要吸引你加盟，对于没有经验的工程师来说，无论是选错了技术路线，或者入错了公司，代价都是高昂的。往大来说，我们现在已经陷入了一个知识悖论：我们掌握的信息越多，就越需要其他更知情的人的判断和评估。信息只有经过过滤、评估和评论才有价值，但是目前的体系还没有准备好应对。不过nemil把自己创业过程中遇到的各种忽悠手段进行了总结，用一篇文章和一个Github库对那些忽悠手段和机制进行详细介绍，值得各位工程师和开发者借鉴。

2015年，我跟一位聪明的创业者在交流。他刚刚从一家著名VC那里拿到了几百万美元的融资。在媒体上得到了显著曝光以及招募了部分早期员工后，他的公司开始高歌猛进。他的企业完全依靠一个流行的开源项目。

作为其战略的一部分，这位CEO给了一位核心的开源开发者一些项目股权。有了这个之后，他吹嘘说自己能够更快地获得关键信息，为公司的利益而影响其路线图，并且为他的公司从该（开源）项目招募开发者。

我很怀疑那位开源开发者会不会公开宣传这种关系。他会在会议上热心地介绍这家公司吗（尽管私下有保留）？这会如何影响其他开发者的决定？开发者在其职业生涯早期会不会在没有进行充分思考的情况下跟随他做法呢？

计算机工程师经常要处理自身技术系统被利用的情况，也就是外部第三方利用某个bug或者漏洞。对我们个人信息来源的“利用”或者社会工程——也就是让当事人影响subreddit（子版块）、会议、会面、博客、记者、教授、行业分析师等也应该给人类似的感觉。就像上面的例子那样，甚至你的同行都可以受影响。

作为工程师，尽管这些“说客”渴望影响我们，但形成让我们做出最佳决策（既为了我们的团队也为了我们自身的职业生涯）的抗体是很有价值的。除了识别我们会受到影响的方式以外，我将列出三个技巧来帮助我们更好地做出决策。

影响工程师之战

在全球计算时代，这仅是一场更大规模的战争的一个例子：这场战争的核心是俘获工程师的心。

那些塑造我们观点的群体有很多，以下是一些例子：

• 想卖自己的技术或者发展自己平台的开发者工具团队

• 想招我们进来的公司

• 想要招募贡献者和用户的开源开发者

• 想要投资我们的风投家

• 想要卖课程的培训计划

• 想要我们雇用自己的咨询公司

他们创建和赞助的内容（新闻稿、会面、博客文章、会议、演讲）在我们做出的决策——从我们采用什么技术到我们加入哪家公司都扮演了关键角色。

一篇备受关注的新闻稿（往往会缺失很多数字）也许是加入一家初创企业的主要原因。有关最新数据库技术——比如NoSQL的一篇博客文章或者一次热门演讲可能是试验（该数据库）然后切换的原因。一场大学演讲可能有一部分内容是介绍他们自己公司的技术。某一年Hacker News（HN）点赞最多的帖子也许会影响我们选择采用什么技术。尽管如此，作为这一信息的消费者，我们当中很多人并不会一直都用批判性的眼光去检查该信息及其来源。

在初创企业，基于这些输入做出的糟糕的技术选择会转移焦点，让使命陷入风险。对于工程师个人来说，学错了技术会浪费我们的时间。加入兜售虚假承诺的错误公司会让我们的职业生涯倒退。

例子：招募工程师与初创企业找风投融资

在看到一篇文章称赞一家初创企业做得有多好时，我在VC圈的一位朋友一度笑出了声。因为他之前看过那家公司的pitch，他知道对方现在陷入了困境，那篇文章只是他们在钱烧光前用来吸引投资者兴趣以及继续招募好人才的手段。我知道有很多人本来会从那篇文章得出完全相反的印象。关键是，经过适当的训练后，是有可能弄清楚那篇文章背后的现实的。

比方说，Theranos普及了针刺血检的想法，有可能产生巨大的社会效益。技术人才加盟这家公司的话一定会感到非常兴奋的。

但是很多人会被普遍阿谀奉承的媒体所吸引，而后者又是由别有动机的管理团队和不加鉴别地报道的媒体组织所推动的。尽管投资者损失方面的事情写得很多，但那些受骗加入Theranos的工程师和科学家的损失一样不小，他们将失去好几年哟偶网做出真正有影响力的工作，其简历也会被玷污。

例子：MongoDB开发工具营销

MongoDB是2000年代末发展最快的NoSQL数据库之一，有望提供“现代”数据库体验。

我在探讨MongoDB背后的早期营销策略时，曾经指出过开发工具营销的相关问题，其中包括：

• 受邀出席众多MongoDB会面/会议的演讲者往往别有动机（试图推销自己的咨询服务，推销自己的开发工具产品）。

• 黑客学院和早期程序员博客是推销MEAN栈有价值的联盟，但做法比较隐晦，不像HN/Reddit上见到的那种销售推销。

• MongoDB则会提出几乎每一种用例都应该用他们的数据库解决，但是又不突出解释不同用例的折衷取舍是什么。

• 大学黑客马拉松也是影响早期开发者的手段之一，因为这些人还没有充分理解自己得做出什么样的权衡。

即便我在案例研究中指出了问题，但我在肩负团队使命时还远做不到不感情用事。鉴于此，重要的是至少要确保所有工程师都有一个通用的工具去理解我们看到的一些信息。而在假新闻、选择性事实以及钓鱼行为横行的时代里，这些教训还可以帮助我们评估工程内容以外的很多信息。

看不见的影响

跟之前的营销手法不一样的是，工程媒体的外部影响往往是伪装的。

新闻稿或销售拜访的目的很明确。但当这一内容被用到会议演讲或者启发某人写博客文章时，他们就会模糊其中的界线。在营销预算或者资金充足的情况下，用传递的信息宣传和说服别人变得越来越容易，不管其真实性如何。

这方面我在不同的地方都有过亲身经历。在完成工程学习后，我曾经到帝汶帝力替世界银行工作过。有一天，我们在向一群记者解释我们资助的一个项目的好处。在一位深思熟虑的帝汶人看来，这个项目其实还是有很多争论的，但是我们关注的是世行的看法如何。所以我们用一份赞扬该项目优点的新闻稿把记者打发回家了。

次日，我们的新闻稿一字不差地出现在了当地的一家报纸上，里面并没有提到这是一份新闻稿——它变成了作者的署名文章。这确保了世界银行的关键观点得到分享。但这也引发了一个让我困扰的问题，那些帝汶人会如何利用媒体来做出决策呢？

我试着后来才知道这种现象在全球是如何的普遍。在硅谷，掌握内幕的朋友告诉我说他们对大多数人的信息源——以及不同信息被不加鉴别地内化程度感到不寒而栗。我尤其担心那些初级工程师（比如上大学的和上 r/learnprogramming的）以及那些远离技术中心的人，他们可能并未意识到“香肠是怎么做出来”的。

例子：炒作微服务

关于微服务的好处工程社区争吵得很厉害。我自己的观点是微服务在初创企业圈的流行是围绕着容器化的炒作和营销开支的结果。比方说，可以对比一下一家初创企业有关微服务的博客文章以及Martin Fowler更加微妙的观点。

这些信息很多均来自其他受到的信任别人不能比的工程师，开源团队或者培训计划。这聚焦了一个初创企业工程的常见错误，那就是中等规模公司CTO介绍的产品/技术出现在尚未找到产品/市场匹配的初创企业那里，不管这些东西是否合适。

例子：开发者培训计划

为了增加读者人数、吸引学生，培训计划也不能免不了渴望跟读者互动并且实现内容分发的最大化。一些教师在推动特定技术时会有自己的动机——他们的背景可能也没有经过审查。

Free Code Camp是一个很热门的开发者博客，粉丝超过了35万，这个博客曾经提出过REST已死，GraphQL才是未来的文章（《REST安息吧。GraphQL万岁》）。这篇文章由Free Code Camp的负责人发表，作者是一位正在兜售GraphQL培训计划的人。

我对自己早年的行为进行过反思，所以担心没有经验的工程师看了之后会觉得有必要学习GraphQL，但是并没有意识到其中的各种冲突。另一个老一点的例子是《学习MEAN栈的真正理由：就业能力》——对此我的很多最有智慧的朋友都很不认同。我尤其担心类似这样的内容会对早期开发者群体造成什么影响，因为他们经验不足、考虑不周，不知道如何辨别这些观点。

例子：技术的内容营销

除了直接影响外，工程相关社交媒体上还有令人吃惊的一部分比例是内容营销。这些文章旨在增加价值——但其主要目的是帮助自己的公司推销产品。读者有时候会把这些文章内化为“新闻”，即便它们的目标是卖东西，影响理念转变，或者改善SEO。

Union Square的Fred Wilson曾指出过技术圈的内容营销是如何的普遍，并且鼓励要对信息进行批判性的评估：

那创业者应该如何利用VC提供的知识呢？首先，你应该把它看成是内容营销……

这并不意味着它没有用或者没有洞察力。可能有。但你应该理解支持这一切免费内容的商业模式。内容的制作是为了让你去拜访那家VC，给他们参与到你的种子轮或者A轮融资的机会。Joe在他的推特里面声称不是圣经的那篇博客文章其实是广告。这差不多就是圣经的对立面了，对吧？

出于所有这些理由，我最有智慧的朋友都是利用自己的关系网络去了解现实：同学、特定大学的校友、跟组合公司CEO的坦诚对话（投资者）、跟不同平台提供商朋友的“非正式”谈话、一线工程师文锋犀利的博客。他们的信息来源受到私利的影响较小，能够提供更加客观的看法。大家还可以私下讲一些在公开场合讲起来会让人不舒服的东西。

我的这些朋友对于获取真相（尤其是财务或者技术动机）还有一种根深蒂固的渴望，所以总想了解驱动每一条来源的激励因素是什么。尽管他们表面上也许不那么和蔼可亲，但私底下是非常深刻的批判性思想家。

工程师如何才能做出更好的选择

这些问题有一个基本教训：第一手来源、对真相的共同兴趣以及深思熟虑的工程师是不可替代的。

我已经建立了一个Github库，上面列举了我在自己的创业之旅中见过的初创企业工程决策过程中使用过的输入。每一条我都指出了它们是怎么工作的，同时还说明了可能会如何被别人利用。也欢迎大家补充完善。

除了私利因素以外，工程方面的媒体因为其他一些原因也会歪曲事实。比方说，Hacker News上面每一条点赞都是平等的——这意味着全世界最有思想的专家对某个主题的投票权跟毫无经验的人是一样的。几乎每一个社交而媒体算法都更偏爱互动性而不是其他指标，意味着我们看到的只不过是我们周围人想要读到的东西而已。

例子：加密数字货币部落与社交媒体

在社交媒体上，你周围的人会塑造你的态度，即便工程决策本应基于经验主义和事实。社交媒体群体和算法选择的是确认用户相信的内容——并且把相反的内容放到最不起眼的角落。这种部落主义经常可以在Reddit的加密数字货币子版块上看到，意味着读者消费的是被扭曲的现实。（参见过滤器泡泡https://baike.baidu.com/item/%E8%BF%87%E6%BB%A4%E5%99%A8%E6%B3%A1%E6%B3%A1）

就像Coinbase联合创始人Fred Ehrsam解释那样：

加密数字货币建立了牢固的部落文化。一旦你拥有一种货币，你就会整天想着让那种货币升值。每天你都可以在reddit上面看到加密货币部落主义。子版块炮制和报道支持自身持有的那种货币的新闻。加密货币部落主义有两种表现形式：1）大家宣传自己的货币，2）大家怀疑其他的货币。大家宣传自己的货币是在其子版块上报喜的新闻多于报忧的新闻的证据。

关于如何评估工程方面的媒体，我暂时有三条简单的建议：

1、识别内容背后的动机来做出重要的知情决定

首先，要考虑一下作者/演讲者的动机——不管是直接的（作为公司的员工或者投资者）还是间接的（某位公开演讲者可能是一位想要找零工的顾问或者想找工作/咨询的员工）。

我看文章或者听演讲时，往往会问自己几个问题：

• 背景：他们的技术背景是什么，为什么他们适合讲这个话题？

• 目的：他们的演讲/写博客的个人目标是什么？（比如招募、建立个人品牌、新业务），总会有个目的的

• 冲突：他们会有什么冲突，这会如何影响所传递的信息？

• 分发商的动机：为什么分发商（社交网络、媒体出版）要把这个内容给我看？（谁是点赞者，商业模式是什么等）

如果我们看到某家公司的大量报道时，这往往是这家公司想从我们这里得到什么的迹象。他们的员工有意识地花时间跟记者坐下来或者花时间去写文章。这一定是有所图的。

2、揭穿真相

其次，要渴望了解对方所声称的东西背后的真相。

比方说，公司经常吹嘘说基准测试表明自己的产品最好。但是我们在自己的真实环境下去跑一下测试不难发现真相。

直接看代码库是一种强大的纠错手段（如果有的话）。这是不会有“编造”植入的第一手来源。

回顾技术趋势了解其结局是另一个办法，这类似于事后检验：当我们思考几年后大家会怎么看时，基于我们在过去看到的东西去做出判断，这样更容易对炒作不予理会。

当你不同意或者看到异乎寻常的动机问题时，在网上社区上说点什么。在HN上，你可以发表评论或者文章，哪怕是用一个废弃的账号。新的社交网络设计也许可以让我们跟列举出关键动机的人建立关系。

3、建立一个尊重同行和有思想的专家的社区

第三，检查你做出重要技术决定时所依赖的社区。

有一个受益于真相、批判性思考以及有内容专家的社区非常重要。这可以是前员工、同学或者你的同事。你可以跟能找到的最有思想的工程师辩论。在网上你往往可以在小众的HN文章的评论或者开源邮件列表/聊天室中找到这样的群体。在你的职业生涯早年，找到一位深谋远虑的导师非常关键。

从很多方面来说，这种办法反映出计算机安全的信任网络，我们会寻求自己信任的朋友——以及这些朋友的关系网络帮忙。

这一点突出了由一位不带感情色彩的教师传授的工程课程的好处。我不知道有任何学校会教初级工程师如何用最好的方式去消费工程方面的媒体——或者如何去选择一门技术工具。这通常意味着好几年的时间里我们会容易受到不良意图的诱导，除非我们已经从一支好团队那里吸取了经验教训。

在评估类似采用何种数据库或者如何对进行架构设计这样的深度技术决定时，在我们的社区里有一位有想法的专家也很关键。一些想法不够深谋远虑的专家的危险是，他们对自身能力的自信意味着他们不会对一些根深蒂固的假设提出质疑，也不会在世界发生变化时做出调整。深谋远虑的专家具备内容知识，会表达强烈的观点，但又不会固执己见。

尾声

作为工程师我们跟我们设计的机器学习算法有一些相似性。大家都利用数据对未来决策做出推断。同样地，有一个深思熟虑的、经过挑选的训练数据集，以及当我们的工程输入出问题时做出调整对双方来说都很重要。

除了鼓励批判性思维以及寻找有思想的工程师搭建可信任的关系网络以外，我几乎还没有谈到其他应该讨论的话题。比方说，出于培养更好的工程师的考虑，我们是不是应该讨论一下Hacker News和Twitter的算法怎么改？开源开发者是不是应该进行冲突披露？Free Code Camp这类的热门工程博客是不是得有个工程师小组对内容和作者的背景进行技术评估？我们是不是应该在新手训练营和CS课程传授工程媒体素养？

尽管如此，我还是挺受鼓励的，因为批判性思维和检验假设仍然是工程师和科学家接触世界的自然方式。除了日常我们要解决的工程问题以外，这种理念在其他方面也扮演着关键角色。

原文链接：https://www.nemil.com/musings/hack-an-engineer.html

编译组出品。编辑：郝鹏程。