大多数开发者不是因为没天赋而停滞不前，而是因为一直在保护那些让成长变得不可能的习惯。
我认识一个前端，工作了整整六年。
Vue 2 写过，Vue 3 也迁移了。React Hooks 用得顺手，TypeScript 类型也玩得转。简历上满满的技术栈，看起来挺厉害。
但有一次，线上出了一个诡异的内存泄漏问题，他盯着 Chrome DevTools 看了半小时，最后说了句：
"这种问题我没遇到过，要不先重启一下服务器？"
六年。
这让我开始思考一个问题：工作年限，到底能证明什么？
时间会骗人
软件行业有个心照不宣的假设——资历越深，能力越强。
但现实是，我见过工作三年却能独立设计复杂系统的工程师，也见过写了八年代码却还在对着 Stack Overflow 抄答案的"老人"。
这之间的差距，不是时间造成的。
是选择造成的。
准确地说，是每天无数次微小的选择积累起来的结果：
遇到陌生问题
│
├─ 选择 A：查一查，弄明白原理
│ → 成长发生在这里
│
└─ 选择 B：找个能用的方案，先过掉再说
→ 这里只是在"完成任务"
绝大多数人在大多数时候选的是 B。
一次两次没什么，但三年五年下来，这两种选择会把人送到完全不同的地方。
熟悉感，是最舒适的谎言
在掘金刷了一小时技术文章，感觉今天好充实。
用 Vite 把项目迁移完了，配置速度快了好几倍，感觉自己又进步了。
把组件全都改成了 Composition API，代码看起来更现代了，感觉对 Vue 3 理解更深了。
这些感觉，都是真实的。
但它们未必意味着成长。
熟悉感会伪装成能力。 当你在已经熟悉的方向上又往前走了一步，你的大脑会给你发一个"成就达成"的信号。问题是，这个信号和真正突破认知边界时的感觉，一模一样。
真正的能力提升，往往发生在相反的感觉里：不知所措、一头雾水、反复失败、最后某一刻突然想通。
那种感觉不舒服。所以大多数人会下意识地回避。
我们真正在逃避什么
我在一个技术群里做过一个不正式的观察：
每次有人问"Vue 3 的新特性怎么用"，秒回一堆人。
每次有人贴线上事故的排查思路，回答寥寥无几。
每次有人问"怎么评估一个技术方案的长期维护成本"，基本沉寂。
这不是巧合。
开发者天然会向"有标准答案的问题"聚集， 因为这类问题的反馈是确定的——你要么对，要么错，做出来就有成就感。
但真实的工程问题往往没有标准答案：
- 这个需求要不要封装成组件？
- 现在引入这个依赖，两年后维护成本怎么算？
- 这段代码逻辑正确，但下一个接手的人能看懂吗？
这些问题，回答起来需要判断力，而不是记忆力。
判断力没法靠刷题获得，没法靠看教程获得，只能靠在真实系统里犯错和反思，一点一点地磨出来。
正因为如此，大多数人选择不去磨。
学框架，还是学判断力
这是我见过分隔"够用的开发者"和"真正有价值的工程师"最清晰的一道线。
够用的开发者关心的是实现：
- 这个功能用哪个库最快？
- 这个架构在 GitHub 上 star 最多？
- 这套方案在大厂是标配，应该没问题吧？
真正有价值的工程师关心的是后果：
- 这个抽象引入后，新人上手要多久？
- 这个依赖如果不维护了，我们怎么办？
- 这套设计三个月后需求变了，我们改得动吗？
前者的核心技能是检索能力——快速找到别人的答案。
后者的核心技能是推断能力——在没有先例的情况下做出合理决策。
国内的技术教育体系——从大学到培训班到各种教程平台——几乎把所有精力都放在了培养前者上。
会搜、会用、会调——这套能力能让你找到工作。
但会判断、会取舍、会在复杂约束下做出合理决策——这套能力决定你能走多远。这恰恰是后端 & 架构领域反复强调的核心素养，无论是做系统设计还是处理高并发场景，本质上考验的都是这种推断能力。
"我在努力"的幻觉
聊到这里，可能有人会说：
"不对啊，我一直在学新东西啊。Tailwind 出来我第一时间试了，Bun 发布我当天就搭了环境，Next.js 15 我追得很紧……"
这让我想起一类前端开发者的典型轨迹：
- 年初：用 Create React App 启动一个副业项目
- 三月：迁移到 Vite，"性能更好"
- 五月：换成 Next.js，"要做 SSR"
- 八月：重构状态管理，从 Redux 换成 Zustand
- 十月：考虑换成 Nuxt，"感觉 Vue 生态更顺手"
- 年底：项目还是零用户，但技术栈已经是全新的了
这种模式在独立开发者圈子里极其普遍，在公司里的表现略有不同，但本质一样：
把"尝试新东西"当成了成长本身。
新技术带来的刺激感，和真正理解一个复杂问题时的豁然开朗，在感官上很像。但前者是廉价的，后者需要代价。
真正的成长，需要你在一个系统里待得足够久，久到开始遇到它在边界处的奇怪行为，久到开始真正理解你当初的某些决策有多蠢。
大多数人在这个阶段来临之前，就已经换项目了。
复杂度，是伪装成能力的不安全感
这是个有点扎心的话题。
我见过很多年轻工程师，在写一个后台管理系统的时候，用上了：
- Monorepo 多包架构
- 自定义 CLI 工具
- 完整的微前端方案
- 状态管理加了三层 middleware
功能本身：四个列表页，两个表单。
这不是过度设计，这是用复杂度在证明自己的存在价值。
架构越复杂，越显得专业。引入的概念越多，越像是个"高级工程师"。
但有经验的工程师心里清楚：
复杂度不是能力的证明，是能力的消耗。
维护一套过度设计的系统，会让整个团队的认知负担持续上升。新人看不懂，改动要谨慎，排查要花很长时间。
六个月后，最初那个"聪明的架构"，变成了所有人最不愿意碰的代码区域。
真正困难的事不是把系统做复杂，而是在压力下把它变简单。那需要你对系统有深刻理解，还需要你能抵抗"多加一层保险"的冲动。
大多数开发者做不到。
真正的成熟，是变得更朴素
这是工程师成长路上一个有意思的反转：
越初级的工程师，越痴迷于"高级感"。
越成熟的工程师，越追求"朴素"。
他们在意的东西，往往看起来很无聊：
- 这段逻辑，下一个接手的人能看懂吗？
- 出了问题，我能在十分钟内定位到哪里出错了吗？
- 这个设计，六个月后改起来痛不痛苦？
他们不太关心架构图画出来好不好看，不太关心是不是用了最新的范式，不太关心别人看到代码的第一反应是不是"哇，好厉害"。
他们关心的是：系统能不能在混乱中活下去。
这种转变，通常发生在某次深夜排查线上事故之后，或者接手某个"天才架构"之后不得不独自重构的漫长周末之后。
痛过才懂。
那，什么才是真正的成长？
我不认为有什么神奇的方法论。但有几件事，我观察到真正在进步的开发者普遍在做：
第一，主动暴露在不舒适的环境里。
接那个没人愿意接的历史遗留模块。去看报警日志而不是等别人来说。主动要求参与系统设计讨论，即使你觉得自己还没资格。
第二，在一个系统里待得足够久。
不是说不能跳槽，而是在每个系统里，你有没有真的经历过它从"新鲜"到"出问题"到"你来修"的完整周期？那个周期里学到的，是任何教程给不了的。
第三，刻意训练判断力，而不只是检索能力。
在做每个技术决策之前，试着先想想：这个选择的长期成本是什么？两年后我如何评价今天的选择？
第四，用简单评估自己的理解深度。
能把复杂的事情解释清楚，是一种能力。能把复杂的系统简化，是更高一阶的能力。如果你对某个技术的理解只能用复杂来表达，可能说明还没真的搞懂。
最后
五年经验，可以是真正的五年成长，也可以是同一年的经验重复了五次。
区别不在于你写了多少代码，而在于你有没有在真实的复杂性面前，一次次选择不逃跑。
那些真正变得厉害的工程师，往往不是最聪明的，也不是学东西最快的。
他们只是愿意在不舒服的地方，比别人多待了一会儿。
🤔 聊聊你的经历
文章里提到了几种让开发者"原地踏步"的模式——追新技术、复杂度崇拜、待在熟悉区……
你觉得自己最容易掉进哪个坑？或者，有没有某次"不舒适的经历"，反而让你进步最快？
评论区说说，我很想听真实的故事。
发表于 昨天 17:56
|
查看: 6|
回复: 0
