为遵守任职公司的信息披露规定，文中部门名称均为概括性称呼，部分项目、流程和技术细节也经过省略或泛化处理。文章只记录截至 2026 年 7 月的个人经历与感受，不代表对公司整体情况的评价。
2024 年，我离开工作六年的乐天，进入迅销，也就是优衣库的母公司。岗位仍与软件开发有关，工资有所增长，公司品牌也足够响亮。按照我当时的设想，这次跳槽应该能带来新项目、新挑战，以及一次职业状态上的重新启动。
结果没有这么简单。
如果要概括这些年我在工作中学习到的事，大概是：工程师职业迷茫不一定来自能力不足，也不一定能靠换公司解决。公司可以改变我每天写什么代码、参加什么会议，却不能替我回答为什么工作，以及想成为什么样的工程师。
从一家初创公司进入乐天
2018 年进入乐天前，我在 Jxpress 工作。那是一家经营媒体平台的初创公司，我担任全栈工程师，年收入约为 300 万日元。以现在的眼光看，当时的技术能力只能算初出茅庐，但我对软件开发充满信心，总觉得只要继续写、继续学，技术上的问题迟早都能解决。
那年有猎头联系我，说可以推荐十多家公司。我参加了多轮面试，最后选择乐天，日本规模较大的互联网公司之一。
准确说，也可能是团队先选择了我。我申请的是前端岗位，而当时这类人才相对稀缺，我的经历恰好符合团队需要。两轮面试结束后，猎头很快告诉我，团队决定发出录取通知。
收到消息时，我先是兴奋，感觉过去的努力终于得到回报，随后又反复向猎头确认消息是否可靠。我把这件事告诉家人和朋友，他们都替我高兴。那时的我认为自己确实有些能力，同时也清楚，这份工作来得比预想中顺利，时机和运气都帮了忙。
从一家年薪不高的初创公司进入乐天，我以为自己已经跨过职业生涯中很重要的一道门槛。至于门后面该往哪里走，我并没有认真想过。
懂技术的领导，怎样带领工程师
我在乐天先后经历过两个团队，一个负责西友网上超市相关业务，另一个从事大数据与分析服务。两个团队的负责人都出身于软件开发，这一点很快改变了我对“经理”的理解。
在第一个团队里，管理者不只安排任务。遇到较大的项目，他们需要参与技术设计，中层负责人还会作为技术负责人进入开发过程。工程师碰到困难，可以直接把问题拿出来讨论，不必先把技术问题翻译成管理术语，也不必花很长时间证明问题确实存在。
2020年，我转到了大数据与分析团队，这种感受更明显。数据服务发生问题时，熟悉业务和系统的经理也会参与处理，有些难题最后仍要靠这些资深工程师解决。即使坐上管理岗位，他们也没有完全离开技术一线。
深夜发布、服务器维护、软件升级和数据故障并不少见。在这个团队工作的四年多里，我的重心从单纯开发逐渐转向技术设计、文档、版本发布和故障恢复。部分发布、维护和升级工作安排在深夜，数据出现问题时，我们也需要及时处理。团队虽然有专门的 SRE 人员，但我仍然承担了一部分相关工作。
这段经历没有让我成为某个领域里最顶尖的人，却拓宽了我对工程工作的理解。代码只是系统的一部分，如何设计、发布、维护，以及出问题后怎样恢复，同样决定产品质量。
市面上同时提供开发、大数据和 SRE 实践机会的岗位并不算多，乐天给了我相当难得的成长环境。
不过，环境足够好，不代表一个人会自动找到方向。
我想做的不只是完成任务
在西友网上超市相关团队工作时，我主要负责前端开发。项目里每增加一个模态框，常见做法就是再写一套模板。功能可以交付，但相似代码不断增加，新问题也可能跟着重复出现。
我提出建立统一抽象，通过全局对象管理模态框，需要使用时再进行实例化。为了证明方案可行，我做了设计和概念验证，再交给当时的负责人。方案没有立刻进入现有代码库，这多少让我失望。不过在后续几个项目中，团队最终采用了类似设计。对当时仍处于职业早期的我来说，这件事代表一种认可：我的价值不只在于完成分配下来的页面，也可以参与技术方向的判断。
2021 年末，我又接到一个网页端数据采集 SDK 项目。已有工具无法满足与视频播放行为联动的需求，只能重新设计一套方案。我既负责设计，也是主要开发者，许多东西都要从零开始。
那段时间，我阅读了不少成熟开源项目的实现，研究它们如何组织代码、控制依赖、设计接口，再把能够吸收的部分放进自己的方案。项目规模无法和知名框架相比，但那种工作状态很接近我想象中的产品创作：问题清楚，责任完整，我可以从设计一路做到交付，也有空间持续提高质量。
这类项目让我满足，却没有彻底消除迷茫。问题不在于我应该叫前端工程师、大数据工程师还是 SRE。比职位名称更困扰我的，是当产品没有被认真打磨时，一个工程师究竟能做多少事。
我也在工作之外维护个人项目和开源项目。一方面，我希望为社区解决一些常见问题，也希望别人能够看到我的能力；另一方面，我始终想体验从产品到创业的完整过程。
我羡慕 Fabrice Bellard、Anthony Fu 这样的开发者，不只因为他们技术出众，也因为他们能够长期投入自己认同的方向，持续打磨高质量软件。
而公司里成熟稳定的业务无法完全容纳这种创造欲。团队希望守住已有产品，按照可控节奏逐步迭代；我则更想替换不够好的方案，尝试跨度更大的改进。为此，我提出过不少建议，也做过一些原型，希望团队能够接受。
那时的我并不讨厌具体工作，也不排斥没有最终决策权。只要可以说服领导，只要向上沟通还有作用，我就愿意继续投入。
问题在于，技术方案得到认可，与产品真正改变之间，隔着很多我当时不愿认真面对的东西。
我把跳槽当成一次职业重置
乐天并非没有流程和限制，它也不是完全自由的爵士乐队。项目方向仍由管理层决定，工程师的个人追求也不可能总与团队目标一致。
不过，很多流程掌握在懂技术的高级经理手中，存在讨论和调整空间。团队至少愿意理解工程问题，也愿意让技术人员参与寻找答案。今天回看，乐天接近我喜欢的工作方式，但当时的我更多看到无法改变的部分。
领导曾评价我过于执着技术，视野不够宽，但处理技术任务的能力很强。前半句当时不太容易接受。我认为自己只是认真对待产品质量，也认为那些没有被处理的问题迟早会变成更大负担。从我的角度看，很多事情都有更好的技术方案，只是团队没有投入足够精力。
到了乐天最后一年，我才开始更完整地看待项目。做技术分析和设计时，我不再只考虑代码是否漂亮、架构是否合理，也会考虑业务目标、交付风险、维护成本和相关团队能否配合。
这时再回看领导那句评价，我开始理解所谓“眼界不够宽”指什么。工程师很容易把自己看得见的问题当成最重要的问题，也容易低估资源、组织和商业目标对产品的影响。
这种变化让我接近高级工程师应有的工作方式，却没有消除不满。我依然希望参与更有创造性的产品工作，也依然觉得团队前进速度无法满足自己。
当个人追求与团队目标长期失衡时，我想到的解决办法是换个平台。我没有制定过详细职业规划，只模糊地希望五年后的自己成为更好的工程师，能够做出质量更高、让用户满意的产品。当现实与这个愿望出现距离时，我习惯把问题归因于环境，希望通过跳槽重置掉积累已久的负面思维。
离开意味着放弃六年里建立的稳定关系和内部信誉。临走前，一位高级经理提醒我，迅销的软件产品状况可能不适合一个重视技术和产品质量的人；如果决定离开，最好再寻找更匹配的选择。
我听进去了，却没有因此改变决定。
面试时，我没有从交流中感受到特别深的技术积累，但迅销是大公司，品牌足够有分量，工资也明显增长。我希望工作内容和挑战随之升级，于是把已经出现的疑问解释成行业差异，认为进入后总能找到自己的位置。
现在看，那次决定有些冒进。
当工程师无法决定如何改进工程
加入迅销后，我逐渐发现，服装零售企业中的技术部门与互联网公司有不同出发点。互联网产品往往直接依靠软件创造和交付价值；在零售企业中，软件更容易被看作支持业务运转的工具。这个区别本身没有对错，却会改变工程师在组织里的位置。
最直接的感受来自需求。一项任务有时只有简短标题，背景、边界和验收条件并不完整。开发工作开始前，我需要自己寻找相关人员，逐一确认目标和责任范围。与此同时，多项任务并行推进，工程师不仅承担开发，也被迫补上部分需求整理、资源协调和项目管理工作。
我并不排斥职责边界模糊。在一个像初创公司那样拥有自主权的团队里，工程师多做一些产品和管理工作，反而能扩大视野。问题在于，责任增加时，决策权和资源并没有同步增加。
我也遇到过值得长期交往的同事。即使环境不理想，仍然有人认真工作，努力改善眼前问题。
我所在的范围里，工程团队很难自行安排技术改进。业务功能持续进入排期，技术债、测试和基础设施改造即使获得团队认同，也可能长期找不到实施机会。历史系统之间存在复杂依赖，一处小改动可能牵动多个部分，团队只能投入更多沟通和验证来降低风险。
这种状态最消耗人的地方，不是工作难，而是许多困难本来可以通过长期建设减少，却始终没有足够空间处理。工程师忙于完成一个又一个任务，系统却没有因此变得更容易维护。
乐天高级经理在我离职前的提醒，已经指出了潜在问题。面试时的不安，也提供了另一个信号。我没有继续追问，而是用“大公司不会太差”说服自己。现在看，我高估了品牌可以提供的信息。公司规模能说明业务体量，却不能直接说明工程文化。员工数量能说明投入，却不能说明工程师拥有多少决策空间。
一个组织把什么排进日程，才说明它真正重视什么。所以当 2024 年我进入迅销后，工资增长实现了，工作内容却开始开倒车。
爵士乐队与责任链
迅销强调员工主动承担更多责任。工程师不仅做工程，也需要参与部分本应由产品或管理角色完成的工作。从正面看，这确实会扩大视野，让人更熟悉组织如何运转。
不过，更多任务不等于更多成长。
如果工程师同时处理多个项目，注意力不断切换，又缺少决定优先级和改进方向的权力，那么所谓“承担责任”很容易变成单纯增加工作量。一个人可以因此变得熟练，知道如何在混乱中完成任务，却未必能建立更深的技术判断或产品能力。
我喜欢Notion创始人的那种比喻方式：把理想团队比作一支爵士乐队。每个人拥有自己的能力和判断，可以根据现场变化进行即兴创作，又能围绕同一个主题形成合作。
这种团队不等于没有流程。它需要成员能力相近、目标清楚、资源共享、任务安排合理，也需要允许有限失败。完全取消流程只会带来混乱，但如果所有决定都被流程提前锁死，工程师也只剩下执行。
迅销让我更具体地理解了责任链。基层工程师开发的软件一旦出现严重问题，管理层同样需要承担评价和管理责任。在这种机制下，一个无法证明短期收益的技术改进，很容易被视为额外风险。管理者更愿意优先完成确定的业务任务，也不愿为可能失败的工程尝试承担后果。
我不认同这种资源分配方式，却开始理解它为什么稳定存在。每个人都在现有评价机制中保护自己的目标，最终形成一种稳定状态：业务得到更多功能，管理者减少不确定性，工程师继续背着技术债前进。因而在工程师这里的个人热情很难打破已经形成的责任链。
公司里也存在少数愿意保护工程判断的领导。他们懂技术，也愿意在上层要求与工程质量发生冲突时提出不同方案。只是这类人很少，普通工程师也很难单靠个人热情改变资源分配方式。
我曾以为，自己缺少的只是更好的技术。
迅销让我看到，很多技术问题最后都是组织问题。
迷茫只是换了一种形状
在乐天，我的迷茫是：“产品还有很多地方可以做好，我应该怎样推动它？”
到了迅销，问题变成：“如果组织并不为这些改进留下空间，我为什么还要不断消耗自己？”
两种迷茫看起来相似，来源却不同。前一种带着技术人员常见的急切，总觉得再努力一点就能接近理想；后一种更接近无力感，因为技术能力无法直接改变资源、责任与决策方式。
过去我羡慕 Fabrice Bellard、Guillermo Rauch、尤雨溪和 Anthony Fu 这样的开发者。他们各自做出了有影响力的软件和工具，也表现出我向往的产品判断力。我阅读过不少相关项目代码，试图理解高质量软件如何被设计出来。
我过去相信，好技术迟早能够推动好产品。工作多年后，我开始明白，产品质量的上限，往往取决于组织愿意为它留下多少时间和决策空间。
时间尤其重要。持续打磨产品需要能够自主决定的时间，也需要团队允许人把注意力放在长期质量上。没有这种空间，再有上进心的工程师也只能不断处理眼前任务。
更多责任也不必然带来成长。一个人可以因为任务越来越多而变成熟练工，却未必因此成为能工巧匠。
这并不意味着工程师可以把所有问题都推给公司。组织决定外部边界，个人仍然需要判断该学什么、接受什么，以及什么时候应该离开。我的失误，是长期没有明确职业计划，只模糊地希望五年后的自己成为“更好的工程师”。
当现实不符合这个想象时，我不知道应该调整目标、改变做法，还是更换环境。最后，我选择了最容易执行的一项：换公司。
两家公司留下的两把尺子
乐天留给我的，不只是前端、大数据和 SRE 经验，还有一套判断工作的尺度。
官方称它为“乐天主义”，由五项品牌理念和五项成功原则组成，包括持续改善、专业主义、客户满意度、速度，以及“假设—执行—验证—机制化”。这些表达有明显的企业文化色彩，却在我做对或做错事情时提供了参照。乐天主义官方说明
其中对我影响最深的，是客户满意度。只要用户愿意使用一个产品，我就认为他们值得更好的体验。这种执着有时让我过度关注技术，忽略商业目标、资源限制和组织关系；但它也让我无法对明显可以改善的问题完全视而不见。
迅销则给了我另一把更现实的尺子，团队重视业务，你的工作内容需要围绕这个价值中心来展开。它让我开始观察技术之外的条件：领导是否理解工程，能否掌握团队资源和任务量；团队是否具备基本能力与一定自主权；用户价值是否明确；开发流程是否支持长期质量。
现在判断一份工作时，我会先看领导是否理解技术，能否掌握团队资源与任务量；再看团队是否具备基本工程能力和一定自主权；随后才是用户价值、产品竞争力和开发流程。
这些标准并非来自职业规划，而是从一次判断失误里长出来的。
如果重新选择，我仍会进入乐天。它并不完美，但在我经历过的公司中，它更愿意把工程师当作可以共同解决问题的人。我不会再次以同样理由选择迅销，因为工资和品牌无法抵消工作方式与个人价值之间的长期冲突。
我不再期待下一家公司替我完成“重置”
截至 2026 年 7 月，我仍在迅销工作。迷茫也没有得到一个干净、彻底的答案。
变化在于，我不再把“不迷茫”当作目标。职业身份会变化，兴趣会变化，环境同样会变化。我更需要一个能够让自己保持投入，也能提醒自己继续前进的方向。
如果能对 2018 年刚进入乐天的自己说一句话，我会提醒他多接触优秀的人，也不要把技术能力看得过于万能。优秀方案不会自动变成优秀产品，工程师也不会因为看见问题，就自然拥有改变问题的权力。
能做的仍然是尽力改善、继续积累，同时判断眼前组织是否值得投入。个人追求与公司目标很难永远一致。出现短期偏差时，可以沟通、调整和等待；长期失衡时，也不必把所有问题都解释成自己不够努力，最好重新判断眼前平台是否值得继续投入。
换一家公司，有时能改变处境，却无法替一个人定义自己。
至少下一次站在岔路口时，我不会只问工资、品牌和岗位名称。我也不会把组织的问题全部变成对自己的怀疑。
我会先看组织，再谈技术。
