我认为对开发者来说情况不同。他们知道对于其他人（甚至对于他们的上级），他们只是在做神秘的、抽象的“工作”。根据我的经验，很多开发者学会利用这一点来说服自己和上面的每个人，让他们相信他们必须进行完整的重构。我认为，这一切都归结于管理层仍然无法评估开发者的的工作质量（甚至真实性质）。当然，有一些管理者本身是开发者，但他们与上面的人说话时用的是非常不同的语言，所以他们很容易说服高层管理，让他们（和他们的团队）做正确的事情。我在这里并不责怪任何人，我们只是比其他人稍微被压榨一点的工人。但作为一名不太喜欢在工作中摆弄东西的开发者，我见过很多事。这个行业从未停止根据代码行数（LoC）来提拔开发者，而不管业务效率如何。…
源讨论当“R”从研发（R&D）中消失时（2021）原帖 104 条评论 · 导入时统计这有什么效果吗？通常来说，组织架构中层级较低的人比靠近核心的人权力更小，所以我预计这种投诉会被搁置，没有任何实际操作。
完整原文把你的经验，加入这段讨论。
哦，这是一条很难走的路，同样，在没有 hindsight 的情况下，很难知道正确的路径是什么。 我遇到很多情况，一些真正聪明的开发者，他们用自己开发的子系统替换了标准的子系统，通常是出于性能原因。 在那一刻，在那个背景下，通用的解决方案性能较差或者有丑陋的错误，或者其他原因，所以他们用一个专门为特定上下文设计的东西替换了它。 但后来上下文发生了变化，现在这里有一个被狭隘设计的混血儿，而且为了性能进行了优化（所以很难维护或更改）。而开发者已经去了其他地方。 但同样，我整个职业生涯都在编写“新的标准解决方案”，当然，这最初是作为“标准解决方案”的替代品而出现的。在我们的背景下，这确实带来了巨大的变化。所以如果我对此说些矛盾的话，那就太虚伪了。…
完整原文对于一些老板来说，你描述的这种情形属于‘杀死你的英雄’这一概念。 有时候这个人确实很出色，你应该做任何事情来留住他们。但如果只是因为他们是唯一理解自己代码的人，那么他们就是一种隐患。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。