原文Taylor

+10x 工程师可能是神话,但 -10x 工程师确实存在。

要成为一个 -10x 工程师,只需每周浪费 400 小时的工程时间。

请结合以下策略:


使 10 名工程师的产出无效

尽可能在开发阶段改变需求。为了避免指责,从一开始就模糊需求。

创造 400 小时的无效工作

让你的团队执行看似在工作的任务。常见的例子包括演示文稿、图表和票据管理。创造毫无意义的仪式。

创造 400 小时的倦怠和离职

毫无感恩之心。推卸责任。制造混乱。发怒。导致他人加班。

将 10 名工程师困在技术讨论中

让工程师讨论想法。鼓励他们追求优雅而非实用。确保没有人有权做出任何决定。

增加 400 小时的沟通负担

让会议破坏日程安排。为了不显眼地浪费他人的时间,撰写冗长的信息/文件,并尽可能广泛地分享。欢迎所有意见,追求参与度。

浪费 10 周工资在云成本上

编写运行缓慢的程序。避免使用数据库索引。在 16 核机器上运行单线程程序。选择带有高级 RAM 和 GPU 的特殊硬件。大量将数据存储在 RAM/磁盘上。不压缩任何内容。不重视数据布局。

创建无用的工具

认为现有的解决方案无法满足你的需求。编写只有一个人能理解的脚本。如果脚本做了重要的事情,避免编写相关文档。

增加 400 小时的编译/构建时间

慢速构建浪费时间并会产生复利效应。随着构建时间的增加,开发人员更容易分心。为了确保开发人员进行上下文切换,重新编译至少需要 20 秒。你也可以编写慢速测试,以达到类似的效果。

编写无意义的测试

在不测试底层功能的情况下,创建对特定变量的依赖关系。模拟函数调用,直到没有原始代码运行。在测试中引入微妙的随机性,使测试无缘无故地成功/失败。

浪费 400 小时在糟糕的架构上

完全不考虑系统设计将如何随时间演变。或者,让你的团队沉迷于架构决策,以至于没有时间测试他们的假设。

浪费 400 小时在部署上

创建尽可能多的环境。生产和测试环境必须有很大的不同。用脆弱的构建系统启动脆弱的代码。频繁迁移数据库。

因客户不满而损失 10 周工资

屡次检测不到严重的漏洞,也不解决它们。不重视安全漏洞。

编写毫无价值的文档

在私信中解释代码。编写没人使用的 wiki 文档。

将 10 名工程师困在徒劳的创新项目中

吸引优秀工程师并浪费他们的潜力。向管理层低估项目的难度;夸大项目的实用性。告诉管理层项目“几乎完成”,直到他们放弃它。

增加需要 400 小时维护的依赖项

让工程师单独学习每个库。

延迟转变方向

永远不承认失败。让你的团队淹没在沉没成本中。忽略可以改善状况的 80/20 折衷方案。

(注:80/20 折衷方案指的是通过专注于最重要的 20% 的工作或资源,可以实现 80% 的目标或效果。)

聘用 10 名 0x 工程师

机会成本可能致命(错失聘用更优秀人才的机会)。拖油瓶可能不会积极伤害你的团队,但他们占据了可以提供积极帮助的人的位置。

聘用 5 名 -1x 工程师

不要满足于拖油瓶。积极聘用那些会引发灾难且抗拒学习的工程师。

防止 10 名 -1x 工程师被解雇

不揭露或处理潜在的问题。不留下失败的书面记录。为糟糕的工程辩护。

增加 400 小时的 bug 分类

编写无法调试的程序。在所有内容上增加抽象层。编写杂乱无章的代码。让一切都对初始条件敏感。避免使用纯函数。大量使用依赖项。尽可能说“在我的机器上可以运行”。