有没有人为了reset跳槽

程序员为“Reset”跳槽：从“fully own”到“co-own”的责任权衡与职业发展

该帖深入探讨了程序员是否会为了摆脱维护多年的“屎山”代码库而选择跳槽，核心矛盾在于长期面对难以维护的代码，作者怀念早期项目结束即可翻篇的体验，并询问是否存在不以升职加薪为目的，纯粹为了“Reset”而跳槽的案例。讨论中，AI时代“屎山”价值的争议、好老板的稀缺性以及“屎山”中蕴含的复杂业务逻辑是主要焦点。新增回复进一步强调了“拒绝fully own”的说法，并反问是否是“co-own”（共同拥有）的意图，暗示了对承担Oncall debug等责任的抗拒，倾向于分散责任以避免潜在的甩锅风险。

1. 关键信息

• （之前已归纳）作者因长期维护项目导致代码成为“屎山”，萌生为“Reset”而跳槽的想法。
• （之前已归纳）担忧“好老板”难得，以及自己写的“屎山”是否需要自己承担。
• （之前已归纳）有人认为AI时代，“屎山”的护城河正在被AI瓦解。
• （之前已归纳）也有人认为AI难以理解复杂的业务逻辑和历史信息，真正的“屎山”AI仍难胜任。
• （之前已归纳）有用户分享了跨专业转岗（如硬件转软件）可能面临降级的情况，也算一种“Reset”。
• （之前已归纳）有观点认为，不写注释、不重构，保留核心业务逻辑的独特性，是避免被轻易取代的方式。
• （之前已归纳）有用户分享了自己维护了三年的核心代码库，在公司重组后被交由印度团队重构，尽管自己贡献巨大，但影响力和薪资（comp）反而被降低，导致其考虑跳槽。
• （之前已归纳）用户认为当前技术领域“护城河”不再，除非是极具知名度的个人，否则大多数人都是可替代的。
• （之前已归纳）用户表示即使收入持平，也愿意跳槽去探索新机会，认为五年内深陷一个技术坑（舒适圈）不利于个人发展。
• （之前已归纳）有观点认为，“有测试的屎山”是不合格的，暗示了代码质量与可维护性之间的关系，以及测试在代码维护中的重要性。
• （之前已归纳）有用户提到身边有美国人为了“Reset”而去读Master学位。
• （之前已归纳）关于重构代码时测试集的处理，有观点认为“对应interface的测试集不许碰”，而内部unit test可以随意修改。
• （之前已归纳）最新回复指出，“Reset”不过是从自己维护的“屎山”代码库，换到别人维护的“屎山”代码库开始。
• （之前已归纳）回复者表达了对“fully own”一个方面的抗拒，担心Oncall debug出问题时责任会硬抗，倾向于分散责任。
• 新增：回复者引用了“拒绝fully own”的说法，并反问是否是“co-own”（共同拥有）的意图。
• 新增：回复者认为，不必纠结于“co-own”还是“team”（团队），关键是将该写的文档（doc）写好并保留。
• 新增：回复者强调，避免成为“solo hero”，在不获益的情况下将自己置于危险境地。
• 新增：回复者指出，Ownership（所有权）除了在相关的评级（rating）和晋升（promo）时可能被掌握，其他时候可以“给出去”。
• 新增：回复者认为，最终能写在简历上、面试时能说出来的才是自己的，Ownership等说法仅是“在岗的说法”，本质是“该混就混”。

2. 羊毛/优惠信息

• 无

3. 最新动态

• 无

4. 争议或不同意见

• （之前已归纳）关于AI处理“屎山”的能力：有人认为AI已能处理大部分“屎山”，而有人则认为AI难以理解深层业务逻辑和历史信息。
• （之前已归纳）关于跳槽动机：大部分人认为跳槽最终还是为了钱，单纯为了“Reset”的理由不被普遍认同。
• （之前已归纳）关于“屎山”的价值：有人认为“屎山”是个人技术能力的体现，也有人认为在AI时代价值降低。
• （之前已归纳）关于个人在核心代码中的价值和可替代性，有用户经历表明即使是核心贡献者，在公司变动后也可能面临价值被低估和被替代的风险，这与“护城河”的讨论形成对比。
• （之前已归纳）关于“屎山”的定义和质量标准，有观点认为“有测试的屎山”本身就是不合格的。
• （之前已归纳）关于重构代码时对测试集的处理方式存在不同看法，一方认为应保护特定测试集，另一方认为内部单元测试可随意修改。
• （之前已归纳）关于“Reset”的本质，有观点认为这仅仅是从一个“屎山”跳到另一个“屎山”。
• （之前已归纳）关于承担责任的意愿，有人倾向于避免完全负责某个技术领域，以规避潜在的Oncall风险和责任追究。
• （之前已归纳）关于“fully own”的责任承担模式，有回复者提出了质疑，暗示了对这种模式的潜在抵触，并抛出了“co-own”的可能性。
• 新增：关于“fully own”的责任模式，有回复者提出了质疑，暗示了对这种模式的潜在抵触，并抛出了“co-own”的可能性。
• 新增：对于“co-own”或“team”的责任模式，存在不同看法，有人认为关键在于文档记录，而非责任划分的模式本身。
• 新增：关于Ownership的价值，有人认为其主要体现在评级和晋升，而非日常工作中的实际意义。

5. 行动建议

• （之前已归纳）如果没有身份顾虑且跳槽工资不降，可以考虑为“Reset”而跳槽。
• （之前已归纳）考虑换组或内部转岗，可能是比跳槽更稳妥的“Reset”方式。
• （之前已归纳）保持自身成为“大动脉”的价值，例如通过保留核心业务逻辑的独特性。
• （之前已归纳）对于“屎山”的重构，有人提出利用AI和测试集的方法。
• （之前已归纳）在维护代码时，应确保代码质量，避免引入“有测试的屎山”，注重测试的有效性。
• （之前已归纳）鉴于当前技术领域的可替代性高，个人应积极寻求新的发展机会，即使是收入持平的跳槽，也可能带来更广阔的职业前景，避免长期处于舒适圈。
• （之前已归纳）在公司重组或外包的背景下，个人应警惕“技术护城河”的脆弱性，避免在一家公司过度停留，建议在4年包裹（cliff）前考虑跳槽。
• （之前已归纳）在进行代码重构时，明确重构范围和边界，保护好关键接口的测试集，同时内部单元测试可以灵活修改。
• （之前已归纳）对于“Reset”的看法，需要认识到跳槽可能只是从一个“屎山”转移到另一个“屎山”，需审慎评估。
• （之前已归纳）在技术职业发展中，可以考虑分散责任，避免完全“fully own”某个技术领域，以降低Oncall debug等潜在风险。
• 新增：对于“fully own”的责任模式，可以考虑探索“co-own”等更分散的责任承担方式，以规避潜在的风险。
• 新增：在工作中，应注重记录和文档编写，将重要成果体现在可展示的文档中，而非仅仅依赖于“Ownership”的口头说法。
• 新增：避免过度承担“solo hero”的角色，在不确定的情况下，应谨慎评估风险，避免将自己置于不利地位。
• 新增：认识到Ownership在职业发展中的实际作用，主要体现在评级和晋升机会上，应理性看待其在日常工作中的意义。
• 新增：在职业生涯中，应采取“该混就混”的态度，将精力集中在能够转化为实际成果（如简历上的内容）的事情上。