「面试造核弹，入职拧螺丝」大部分软件工程其实就是管道作业

我最近在网上读到一篇有关软件工程师电话技术面试的文章，为了拿到 offer，一个工程师必须在电话里完成一个非常复杂的代码挑战。他表现得很好，也拿到了 offer，但在加入公司后，他发现他所做的工作与预期相去甚远。他的主要任务就是为运行在虚拟机上的遗留系统构建基本的 CRUD。

在招聘中，这类情况一直在发生。我们让工程师通过严格的筛选程序，问他们一些有挑战性的问题，但在把他们招进公司之后，只是让他们做一些枯燥乏味的事情，比如负责由五六个服务组成的系统，或者让页面看起来更漂亮些。我并不是说这些任务就不需要技能，只是这些任务所需要的技能与大多数面试涉及的内容根本不一样。

剥掉糖衣

软件是因为能够提供业务价值，所以才被创建出来。

虽然阅读有关软件工艺的书籍并且在软件技术上追求卓越对我们来说颇具吸引力，但归根结底，如果不能形成业务并从中赚到钱（或省钱），我们的工作就毫无意义。

因此，软件行业的现状自有它的道理。就像水管工一样，他们获得报酬，是因为他们了解自己所使用的工具，并知道如何使用它们让设备运转起来，而不是让他们重新发明技术，或者花 80 个小时去优化只有 5% 的用户会用到的东西。

正视问题

中小型企业很少会去处理与规模扩展或优化相关的问题——一部分原因是硬件变得越来越便宜，一部分原因是基础的开源软件已经做得很好了。这是一件好事，作为软件开发人员，我们应该拥抱这样的现实。

现在让我们回到管道问题上。想象一下，你拥有一家带有一个洗手间和 10 名员工的小餐馆。你每周有几百个顾客，其中 10％可能会使用你的洗手间。显然，你必须要有一个洗手间，但它是否需要比你家的厕所更高档或更先进？你需要 10 个隔间、活动龙头、戴森干手器和大理石柜台吗？可能不需要，除非你想要表现你的阔气。

然而，我们却一直在初创软件工程领域做着类似的事情。

一家拥有 5 到 10 名员工的小型企业，他们在构建 SaaS Web 应用程序时需要一个可靠、安全的系统，但这个系统是否需要比现成提供的服务更强大？是否真的需要基于人工智能的搜索？是否真的需要为每个团队成员提供实时的仪表盘？是否真的需要微秒级的主页加载速度？是否真的需要为发布的每个功能进行拆分测试？可能不需要，除非你想要表现自己有多“成功”……

就像优秀的小企业主应该雇用知道如何使用标准工具修理洗手间的管道工并按照市场行情支付他们报酬一样，优秀的工程经理应该聘请知道如何使用行业标准工具来开发可靠软件的团队成员，并按市场行情支付他们报酬。

然而，我所看到的很多工程经理的做法都是相反的。他们在面试中给人的印象是，他们雇用的每个人都必须是高级工程师，必须具备“大数据”经验，或者必须深入了解每种排序算法。

我们犯了过度工程的罪

另一个问题是我们的软件过度设计了。从这方面讲，我也是有罪的。

我刚加入 Graide Network 公司就立即开始将遗留应用程序分解为微服务。现在，我不得不为新来的开发人员提供自定义工具，以便让他们在本地计算机上把系统运行起来——而在我们的业务生命周期中，这并非真正值得花费时间的事情。

这也让我自己很难招到人。我不想将候选人限定在了解多个特定 Web 框架、Docker 容器、微服务、Redis 和 MySQL 的工程师身上，但我已经把自己逼到了这样的角落里。最近我才意识到这一点，并开始考虑简化我们的技术栈，以后我会另写文章来说明。

投资者犯了“压迫”我们的罪

另一方面是来自投资者和媒体的压力。在初创领域，这一点尤其明显，因为我发现投资者就像记者那样喜欢抓住一些热词不放。

“哦，所以你正在开发一个应用程序？它使用 AI 了吗？区块链呢？拿我的钱去做吧！“

于是你把自己卖给了投资者，成为一家 AI 或区块链公司，所以你必须聘请这方面的工程师，即使你不确定这样是否真的能够帮你建立起更好的业务。于是你避开了那些在现有技术领域拥有超过 10 年经验的候选人，把橄榄枝伸向了那些追逐热词的小鲜肉。这就像聘请了一位只有 3 年经验却自己发明了工具的水管工，高风险、低回报。

我们该怎么办？

我们生活在一个大多数“软件工程”基本上就是管道作业的世界里。我们该怎么办？这对于我们的职业生涯来说意味着什么？现金流会一直持续下去吗？

首先，我们应该认识到并接受这样的一个事实，即我们可以用更少的资源构建更多的东西。也就是说，我们工作中不是那么有价值的部分可能进行自动化，或者构建工具，让业务人员为我们做这些工作。例如，每当我的团队中有人想要修改自动电子邮件副本时，我就要去修改代码。而现在，他们只需要在可视化编辑器中编辑模板，我甚至都不知道它们被改过了。

其次，我们在设计系统时需要考虑到系统的复杂性。如果有现成的解决方案，那么就用它，不要再从头开始构建。我们要学会组装零件，这样就可以比那些每次在启动项目时都要自定义构建框架的软件工匠更高效、更快、更好。

第三，我们应该设定切合实际的期望。大部分编码工作都只要求 CS 学位，而这些工作所涉及的内容可能只比知道如何导入库和了解 HTTP 原理多那么一点点。不过确实有些工作需要进行微优化，但这类工作可能很少，而且离我们很远。你的软件可能没有你想象的那么特别。

最后，不要陷入了舒适区而不能自拔。这并不是软件工程师的普遍看法，但我相信在这个领域里，有很多人拿到的报酬已经远远超出了他们所从事工作的难度。有时候是因为他们是这个领域唯一知道怎么做这些事情的人，有时候是因为他们所在的公司无法从人才市场上招到更好的人，有时候是因为其他工程师故意过度设计，这样初级开发人员就需要花费很长时间才能理解它。无论如何，如果我们想要保持高薪和不被踢出局，就不能停止学习。加强知识的广度和深度，并学会如何将炒作从真正的突破性技术中过滤掉。

原文链接：

https://www.karllhughes.com/posts/plumbing