如何成为一名-10倍工程师
+10 倍工程师听起来可能是个神话，但-10 倍工程师确实存在。 想要成为一名 -10 倍工程师，你只需要按照以下原则，每周浪费 400 个小时就行了：
使 10 位工程师的产出归零。
尽可能晚地更改需求。 为避免责备，从一开始就模糊化需求。
制造 400 小时的瞎忙。
让你的团队执行那些看起来像工作的任务。 比如演示文稿、图表和工单管理。创建毫无意义的仪式。
制造 400 小时的倦怠 / 人员流动。
不感恩。 推卸责任。散布困惑。发脾气。导致他人加班。
在技术讨论中劫持 10 位工程师。
让工程师们讨论想法。 鼓励他们追求优雅而非实用主义。确保任何人都无权做出任何决定。
增加 400 小时的沟通开销。
会议毁掉日程表。 为了不引人注意地浪费他人的时间，撰写冗长的消息 / 文档并尽可能广泛地分享。欢迎所有意见，并以提高参与度为目标。
在云成本上浪费 10 周的工资。
编写运行缓慢的程序。 避免使用数据库索引。在 16 核机器上运行单线程程序。选择带有炫酷内存和 GPU 的奇异硬件。在内存 / 磁盘上随意存储数据。不要压缩任何东西。不要注意数据布局。
创建无用的工具。
认定现有解决方案不能完全满足你的需求。 编写只有一个人能理解的脚本。如果脚本做着重要的事情，请避免编写文档。
增加 400 小时的编译 / 构建时间。
慢速构建浪费时间并产生复利。 随着构建时间的增加，开发人员更有可能分心。为确保开发人员进行上下文切换，重新编译应该至少需要 20 秒。你也可以编写慢速测试来达到类似效果。
编写毫无意义的测试。
测试只关注代码中非核心的、易变的数据（比如一个特定的字符串或数字），而不是验证函数的核心业务逻辑。 过度使用 Mocking（模拟）。 在单元测试中，将待测函数所依赖的所有子函数全部用模拟对象替代。在测试中引入微妙的随机性，使其无缘无故地成功 / 失败。
在糟糕的架构上浪费 400 小时的时间。
对系统设计将如何随时间演变不作任何考虑。 或者，驱使你的团队沉迷于架构决策，以至于他们没有时间来测试他们的假设。
在部署上浪费 400 小时。
创建尽可能多的环境。 生产环境和预演环境必须有天壤之别。用脆弱的构建系统启动脆弱的代码。频繁迁移你的数据库。
在不愉快的客户身上损失 10 周的工资。
反复的检测不出和解决严重的错误。 不注意安全漏洞。
编写毫无价值的文档。
在私人消息中解释代码。 编写没人使用的 Wiki。
将 10 位工程师困在徒劳的 “臭鼬工厂” 项目里。
吸引聪明的工程师并浪费他们的潜力。 对管理层低估项目的难度；对管理层夸大项目的用处。告诉管理层它 “快完成了”，直到他们将其取消。
增加需要 400 小时维护的依赖项。
工程师们需要分别学习每一个库。
延迟转向。
永不承认失败。 让你的团队淹没在沉没成本中。忽略可以改善你处境的二八原则妥协方案。
雇佣 10 位 0 倍工程师。
机会成本是致命的。 冗员可能不会主动伤害你的团队，但他们占据了原本可以积极帮助团队的人的座位。
雇佣 5 位 -1 倍工程师。
不要满足于冗员。 积极雇佣那些会造成灾难并抵制学习的工程师。
阻止 10 位 -1 倍工程师被解雇。
不要兴风作浪。 不要留下任何失败的书面记录。为糟糕的工程实践担保。
带来 400 小时的 Bug 分类。
编写无法调试的程序。 用过多的、不必要的抽象层将代码包裹起来。编写意大利面条式代码（译注：指结构混乱、代码逻辑跳跃、控制流复杂、缺乏模块化或清晰结构的程序）。使所有东西都对初始条件敏感。避免纯函数。随意使用依赖项。尽可能说 “它在我的机器上能跑”。