以我的经验，如果你在进行一个全新的项目，你会工作很长时间，但很难看到明显的进展，你必须编写大量代码，做出重要的决定。与此同时，管理层一直在你背后施加压力，问‘为什么还没完成呢’。一旦产品发布，所有重要人物都会从幕后现身，他们显然一直都在背后‘支持’你，然后会有拍照活动，重要人物握手。如果他们觉得特别慷慨，你可能会获得一个桌边的位置。人们开始谈论围绕该产品组建团队，人们争先恐后地想要领导这个团队。但问题是，一旦一切正常运作，他们可能不再真正需要你的专业知识了，一旦一切正常，你作为开发人员就没有谈判的筹码了。他们可能会找一些廉价的初级员工来修复错误并添加缺失的功能细节——雇佣三个初级员工可能甚至不更便宜，重点是管理层不需要再依赖你了，他们可以玩人力资源游戏。……
源讨论人工智能不会取代工作。人工智能的支出是原帖 562 条评论 · 导入时统计作为一名最近被解雇的高级工程师，我的工作被取代了，取而代之的是海外的初级开发人员，他们已经在公司工作了一年以上，按工时计算的生产力相当低，尽管可能如果他们足够便宜的话，花三倍的时间完成工作也是值得的。也就是说，我认为我的被解雇是出于成本削减的考虑，其前提是保留高级人才没有价值，以保持公司盈利，而不是因为 AI 带来了实质性的效益。（因为如果有的话，我比海外的人员和经验较少的本地人员从中获益更多。）
完整原文把你的经验，加入这段讨论。
你对新开发人员能够修复微妙的竞态条件有惊人的信心…… 他们只是添加几个sleep(5)调用来让这些问题消失罢了。
完整原文> "只有我能修复这个复杂的竞态条件，这个竞态条件是在开发半年后出现的" - 如果这个有缺陷的代码足够好，人们半年都没有注意到，那它在接下来的半年里也应该是足够好的，直到新开发人员能够修复它。 根据我在AWS的工作经验，以及最近DynamoDB DNS竞态条件的漏洞，这种思维方式是有问题的。 这些服务内部运作的复杂性非常大。现在这些服务由多个团队组成，每个团队已经经历了多次完全的人员更替。 是的，有一些操作手册和知识传递，但当遇到关键的停机、边缘情况等时，那些维护系统的人与那些曾经构建系统的人对系统的理解是完全不同的。
完整原文> 根据我的经验，如果你在进行一个全新的项目，你会工作很长时间，但看到的可见进展却很少，你必须编写大量代码，做出重要的决策。 有趣的是，这与我的经验完全相反。我参与过的全新项目都有大量可见的进展，并且几乎从第一天起就频繁地向利益相关者更新进展。同样，对于复杂的新功能也是如此。
完整原文我发现这已成为软件开发生命周期的新"元规则"。鉴于这种新的现实，越来越难以真正投资于有抱负的全新项目。在这种新的元规则下，个人贡献者和领导层之间不再相互信任，导致了一个恶性循环，使得启动有抱负的项目变得越来越困难。 很难承诺一个全新的项目，这个项目依赖于领导层不愿承担的风险，因为他们也会承担"交易对手风险"，即专家个人贡献者会利用这个风险来迫使他们完成项目。而专家个人贡献者同样不愿意全身心投入，因为他们知道一旦领导层认为"困难的部分"已经完成，他们对风险的厌恶就会试图用更容易替换的人员来取代这些专家个人贡献者。…
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。