… 管理者应该鼓励工程师花时间去简化架构和减少代码、基础设施和包依赖。聪明的工程师可以随着时间的推移学会简单思考，但这不会自动发生。（我承认在职业生涯的早期阶段我倾向于复杂性，但后来我学到了更好的方法。）管理者应该强调尽可能使用现有的模式，而不是重复发明轮子。专注于交付价值，评估解决方案的依赖关系，以保持简单，并准确地对所讨论的问题领域进行建模。与其与工程师争论实现方法，管理者应该尝试引导工程师自己得出这些结论。我还发现，将简单性作为工程师的关键绩效指标之一是一个有用的工具。
源讨论问HN：如何与过于聪明的工程师合作？原帖 474 条评论 · 导入时统计呃， please 不要听从这个帖子中任何建议“解雇你最高效的工程师”。你将会在一夜之间把你的项目变成一个“遗留”系统。 你是一个经理。你的工作是将他们的重点放在业务成果上。如果你不提供重点，他们就会按照他们自己现有的系统中的喜好问题来行动。这叫做在做他们的工作。 我不建议你担心风格或复杂性。风格是无关紧要的，而复杂性是由业务需求驱动的。不要试图编写能持续100年的软件。一旦你最高效的工程师离开或被重新安排，它就会进入维护模式，再也不会被碰了。
完整原文把你的经验，加入这段讨论。
> 我也发现，将简单性作为工程师的关键绩效指标是一种有用的工具。 我曾经共事过的最聪明的工程师写的代码非常精炼，看起来很简单，但实际上非常巧妙。 我认为关于“聪明”、“机灵”、“易变”的程序员的讨论往往将_代码_的复杂性与机灵程度联系在一起，但很多时候，机灵之处在于找到完美的简单解决方案。
完整原文“简单是一种美德，但要达到它需要努力工作和教育来欣赏它。更糟糕的是：复杂性更容易销售。” —— 伊迪斯格·Dijkstra 复杂性更容易销售，因为它更便宜。这并不是人们通常所说的“复杂性”，比如“看看我写的这个新颖的抽象，并证明它与我们的规范相符”。这是那种随意的、只是为了解决业务问题而添加最简单的补丁的复杂性。这种复杂性最终会导致一团“非常简单”的代码，没有人能完全理解。 它更容易销售，是因为通常人们超速行驶可以更快到达目的地。只有当你被抓住或造成事故时才会成为问题。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。