+10 倍工程师可能是神话，但 - 10 倍工程师确实存在。
要成为 - 10 倍工程师，只需每周浪费 400 个工程小时。结合以下策略：
-
使 10 个工程师的输出无效。
尽可能在开发过程中更改需求。为了避免责备，从一开始就模糊需求。 -
创造 400 小时的忙碌工作。
要求团队执行看似工作的任务。常见的例子包括演示、图表和工单管理。创造无意义的仪式。 -
创造 400 小时的倦怠 / 离职。
不知感恩。推卸责任。制造混乱。生气。让其他人加班。 -
在技术讨论中扣留 10 个工程师。
让工程师讨论想法。鼓励他们追求优雅而非务实。确保没有人有权做出任何决定。 -
增加 400 小时的沟通开销。
会议毁掉日程。为了不显眼地浪费他人的时间，写冗长的消息 / 文档并尽可能广泛分享。欢迎所有意见，旨在促进参与。 -
在云成本上浪费 10 周的工资。
编写慢速程序。避免数据库索引。在 16 核机器上运行单线程程序。选择具有华丽 RAM 和 GPU 的异国硬件。宽松地将数据存储在 RAM / 磁盘上。不压缩任何东西。对数据布局不予关注。 -
创造无用的工具。
决定现有解决方案不完全符合需求。编写只有一个人理解的脚本。如果脚本做了重要的事情，避免文档。 -
增加 400 小时的编译 / 构建时间。
缓慢的构建浪费时间并产生复利。随着构建时间的增加，开发人员更容易分心。为了确保开发人员在上下文切换，重新编译应至少需要 20 秒。您还可以编写慢速测试以达到类似效果。 -
编写无意义的测试。
创建对特定变量的依赖，而不测试底层功能。模拟函数调用，直到没有原始代码运行。在测试中引入微妙的随机性，使其在没有原因的情况下成功 / 失败。 -
在糟糕的架构上浪费 400 小时的工程。
完全不考虑您的系统设计将如何随时间演变。或者，驱使您的团队过于关注架构决策，以至于没有时间测试他们的假设。 -
在部署上浪费 400 小时。
创建尽可能多的环境。生产和预发布环境必须大相径庭。发布脆弱的代码和脆弱的构建系统。频繁迁移数据库。 -
在不满意的客户身上损失 10 周的工资。
反复未能发现和解决严重的错误。对安全漏洞不予关注。 -
编写毫无价值的文档。
在私信中解释代码。编写没人使用的维基。 -
让 10 个工程师陷入无意义的秘密项目。
吸引聪明的工程师并浪费他们的潜力。向管理层低估项目的难度；高估项目的实用性。告诉管理层 “几乎完成” 直到他们放弃它。 -
增加需要 400 小时维护的依赖。
工程师逐个学习每个库。 -
延迟转型。
永远不要承认失败。让您的团队陷入沉没成本。忽视可以改善您情况的 80/20 妥协。 -
雇佣 10 个 0 倍工程师。
机会成本可能致命。死重可能不会主动伤害您的团队，但他们占据了可以积极帮助的人的位置。 -
雇佣 5 个 - 1 倍工程师。
不要满足于死重。积极雇佣造成灾难并抵制学习的工程师。 -
防止 10 个 - 1 倍工程师被解雇。
不要搅动船只。不要留下失败的纸质记录。为糟糕的工程背书。 -
产生 400 小时的错误分类。
制作无法调试的程序。在所有内容上覆盖抽象层。编写意大利面条代码。让一切对初始条件敏感。避免纯函数。宽松使用依赖。尽可能说 “在我的机器上可以运行”。