如何成为一名 -10x 或者 10x- 工程师？-技术圈

频繁改需求

尽可能在开发过程中更改需求。为了避免受到指责，从一开始就模糊需求。尽可能多的使 10 名工程师的产出无效。

要求您的团队执行类似于无效工作的任务。常见的示例包括演示文稿 ppt、图表 excel 和票证报销管理。创建毫无意义的工作仪式。

多写bug，写难以扩展的代码。推卸责任，制造混乱，吵架生气，让别人多加班。

与其反思自己，不如指责他人。

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

多开会议会，破坏他人日程安排。为了不引人注意地浪费他人的时间，请撰写长篇信息/文档并尽可能广泛地分享。欢迎所有意见并争取参与，让更多的人参加，让会议没有主题，让会议成果难以达成。

编写慢速程序。避免 DB 索引。在 16 核机器上运行单线程程序。选择具有高级 RAM 和 GPU 的奇特硬件。在 RAM/磁盘上自由存储数据。不要压缩任何东西。不要关注数据布局。

确定现有解决方案是否满足您的需求。编写只有一个人能理解的脚本和代码。如果脚本执行某些重要操作，请避免编写文档。

缓慢的构建不仅浪费时间，而且会产生复利。随着构建时间的增加，开发人员更容易分心。为了确保开发人员能够切换上下文，重新编译至少需要 200 秒。您也可以编写缓慢的测试来达到类似的效果。

创建特定变量的依赖关系，而无需测试底层功能。模拟函数调用，直到没有原始代码运行。在测试中引入微妙的随机性，以便测试成功/失败而不会产生任何原因。

在糟糕的架构上浪费时间。不要考虑你的系统设计会如何随时间演变。或者，让你的团队沉迷于架构决策，这样他们就没有时间去测试他们的假设。

创建尽可能多的环境。生产和准备阶段必须有很大不同。使用脆弱的构建系统启动脆弱的代码。经常迁移数据库。让磁盘经常写满，不压缩文件、消息等，让网络拥堵。

屡屡无法发现并解决严重漏洞。不关注安全漏洞。

在私人消息或者群消息中解释代码。编写没人使用的 wiki。文档散乱，层层嵌套，描述尽可能模糊。

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

工程师单独学习每个库。多使用新技术，尤其是社区不成熟，生态不完善，文档不全，不稳定的第三方库。Java 中混入 kotlin、lua 等其他语言和脚本代码。

不要惹麻烦。不要留下任何失败的书面记录。为糟糕的工程担保。

编写不可调试的程序。在所有东西上涂抹抽象层。编写意大利面条式代码。使所有东西都对初始条件敏感。避免使用纯函数。自由使用依赖项。尽可能说“它在我的计算机上可以正常工作”。

更多糟糕的实践，参考：https://taylor.town/-10x。