根据我的经验，机会是各占一半。老工程师会说出一些经过艰难学习后的经验教训，比如「不要重新发明轮子，当你的东西已经在带有轮子的系统上运行时」。所以，这是很好的稳固建议，但新手们往往会忽视，当然他们确实会这么做。但有时候老工程师会说出一些更像这样的话：「30年前我深入研究了这个话题，发现了真相，但此后我的判断一直没有更新，尽管世界已经发生了很大变化」。问题是，除非你真正了解事情的内里，或者了解你年长的同事的固有观点，否则很难区分这两种情况。在这种情况下，只有更详细地讨论这个问题，并尝试了解判断的根源，才能有所帮助。然后可能会发现，建议不要使用PHP的警告可能来自于对PHP版本低于1.0的糟糕经历，或者有一些糟糕的经历实际上对于决定项目方向很有用。最终，许多决定都是关于品味的。而没有什么比品味问题更能引发争论了……
源讨论如何在一群专家中领导原帖 137 条评论 · 导入时统计年长的自以为是的工程师真的比你更了解情况的可能性有多大？我认为可能性相当大。 这并不是说共识总是有效。但这意味着团队需要理解反对意见，并做出团队可以接受的决定。最有害的工程情况是经理在不了解后果的情况下做出决定，并且不为结果负责。 有时候有时间压力或难以相处的人，但基本假设应该是人们确实想做出正确的决定，而难以相处通常会让你的生活更困难。谁将负责执行决定，谁将对结果负责？强行让团队接受他们不同意的解决方案会有什么后果？
完整原文把你的经验，加入这段讨论。
我同意这一点。不幸的是，经验是一把双刃剑。我经常和很多老程序员打交道，我不断遇到一些在1999年是正确的事实，但现在已经不正确了。 例如，我最初是在DOS环境下工作的（很多老人都这样）。那时内存非常有限。所以我们养成了非常高效地使用内存（和磁盘空间）的习惯。 比如，使用字节中的位，或者将字节作为ID字段。或者为名字字段的长度而斤斤计较。 所有这些习惯在长远来看都是不好的。而如今内存（和磁盘空间）都很充足。但这些旧习惯很难改掉。 更不用说“现代”技术，比如版本控制等等。 经验很好。我是个支持者。但很多时候，经验也变成了“我在Windows 95中遇到过一个bug，所以这个API调用不可靠”。
完整原文>权衡所有优缺点并做出选择。 当人们同意哪些东西应该放在哪一列时，这是很好的建议 :)
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。