最糟糕的程序员类型
过度工程的架构、“rockstar”开发者和由流行术语驱动的技术选择常被归咎于脆弱、难以维护的系统，但许多人认为根本原因是工程领导力和流程薄弱，而不是个人性格或语言本身。评论者把追逐履历和英雄主义的高雄心编码者，与“无聊”的、防御性的工程师对比起来；后者交付简单、稳定、他人也能维护的代码，并指出管理层常常奖励前者。争论还延伸到语言和工具选择（Rust vs Go、Java 中的 FP、重型框架），以及团队应当偏好富有表现力、复杂的技术栈，还是刻意选择无聊、广为人知的技术以降低风险并改善协作。
根本原因：管理问题，而不是“坏程序员”
- 许多人认为，真正的问题是缺乏或薄弱的技术领导力和流程。
- 非技术管理层往往在不了解取舍的情况下设定时间表和技术方向。
- 让两个“巫师”在没有评审或早期演示的情况下单独构建核心架构，被视为管理失败。
- 激励机制（晋升与炫目的框架技巧、“做架构师”挂钩）会主动鼓励有害行为。
过度工程与技术选型
- 普遍认同在需求尚不清晰前就构建复杂、通用架构是有风险的。
- 若干轶事：Angular/Spring CRUD 应用被严重过度工程化；RabbitMQ 之上自定义协议；“像 Haskell 一样写的 Java”导致性能和稳定性问题。
- 有些人强调 TDD / 迭代式原型开发，以及从可工作的代码中提炼架构，而不是事先进行“架构宇航员式”空想。
Rockstar / 10x 心态与激励
- 那些产出大量复杂代码、垄断知识然后离职的“高绩效者”很常见。
- 管理层往往奖励表面忙碌、代码行数和工单吞吐量，而不是长期可维护性。
- 也有人反驳说，这些“rockstar”往往确实交付更多，把锅甩给他们可能掩盖了低影响力同事和管理层的失败。
团队动态、bus factor 与无聊的代码
- 很多人强烈支持“无聊”的、防御性的、易理解的代码，即使它写起来更慢。
- 团队成功需要文档、指导、代码评审和共享所有权；单打独斗式的英雄行为会造成很低的 bus factor。
- 有几条评论指出，真正的团队开发更慢、沟通更多，但能产出可维护系统。
语言与技术栈之争（Go、Rust、FP 等）
- 有些人认同某些语言（Rust、Scala）和强大的特性集会吸引“为了聪明而聪明”的写法，以及类似 DSL 的代码。
- 另一些人强烈反对诸如“Golang 团队兴旺，Rust 团队 rust”这类泛化说法，并举出成功的 Rust 项目和可疑的 Go 设计选择。
- 共识是：真正的风险在于工具使用不当、把范式强行塞进不匹配的语言，或者选择团队无法共同维护的技术栈。
简单性 vs 反智主义
- 许多人支持将“简单语言和无聊技术”用于 CRUD / 业务应用。
- 也有人认为这篇文章及讨论的一部分带有反智主义倾向，贬低热情、高级技术或表达能力强的语言。
- 建议的平衡是：优先追求简单和团队可理解性，但在高级工具确实能解决实际问题时，不要一概禁止。