今天我要分享的内容是攻城狮如何走出职场困局。这里的困局指的就是事业发展的瓶颈，无论你是刚入行，还是有多年工作经历的，它都可能存在。这个标题很大，接下来我会以我认为的程序员在职业发展中几个阶段会出现的问题或疑问为主线来展开。当然每个人都会有自己的想法，在这里，我不要你觉得，我要我觉得，都听我的😄。
我们程序员一般介绍可能会这么说：我叫xxx，今年xx岁，性别男，爱好——咳咳，不只是女，还有编码。开发是程序员日常最主要的工作，技术是我们安身立命之本，下面就从技术角度出发来聊一聊。下图中左侧为我们的职级体系名称，右侧 P 系列为我们对标阿里技术岗的职级体系（之所以列阿里的，因为它这个体系经过多年的发展，已经很完善，非常具有代表性，好多公司的职级体系都是在此基础上演变而来）。这篇文章主要是写关于前 4 个职级遇到的问题和疑问。
现在前端在阿里达到最高的职级是 P10，代表人物：玉伯。 科普：P 是 Profession，即专业的意思。 常见的还有 T：Technology 技术 M：Management 管理
P5
一般是刚走出校园，初入职场的新人，对应我们初级开发工程师的职级。**这个时期最主要的任务是打好基础，同时要快速学习并掌握工作所需的知识和技能。**此阶段可能会出现的问题有三个：
这里着重说下第二个问题。
从上方学习金字塔的图可见，**教授别人是最好的学习方式。**我们团队每周都会做分享，而每次分享，最大的受益人是谁？听众吗？不，实际上是分享者本人!
做分享至少有三点好处：
- 查漏补缺：为了全面了解所学的知识通常都需要了解很多相关的内容。
以之前刚讲过的函数式编程为例。首先它是一个编程范式，那什么是范式？范是典范、模范，式是方式、模式，合在一起就是编程典型的方式，它是公认的一个东西，用来指导和约束我们程序员对现实世界进行抽象。一般的编程范式有面向对象，命令式、声明式，函数式等多种。其中面向对象可以说是命令式的一种形式，而函数式是声明式的一种形式。除了函数式，像SQL、正则表达式等领域特定语言(DSL)也属于声明式范式，那什么是领域特定语言?它还包括哪些? 到这里你有没有发现即使要弄明白一个知识点，也需要有大量的相关知识储备。因此分享能帮助你发现知识盲区，教你不断去弥补。
- 知识结构化：为了让大家能听懂，化繁为简，就需要对所学内容梳理结构脉络。
你会不自觉地去利用多种问题分析方法，对知识进行分解。比较常用的有5W2H和MECE法。5W2H中文名为七何分析法，它是一种通用的问题分析法，是几个英文单词（What,Why,Who,When,Where,How,How much）的缩写。怎么用呢，以现在比较火的微前端（一种架构风格）为例，这几个单词分别对应：什么是微前端，为什么要用微前端，谁来用微前端，什么时候，什么地方用，怎样去开发一个微前端框架，要花费多少成本。
再来说说MECE，它是《金字塔原理》中重要的分类方法，英文是 Mutually Exclusive Collectively Exhaustive，可以简读为 Me See，翻译过来就是互相独立，完全穷尽。
还是以刚才说的微前端为例，在说明为什么要用微前端时，就需要说出它和一般的单体应用 Monolith 相比有哪些优势。怎么做呢？先把一些能想到的点依次列出来：每个应用都能单独开发、测试、部署；是单体应用的拆分，代码量更少；构建速度更快；从组件级别的复用提高到模块或者应用级别；能够使用不同的技术框架开发。然后将以上内容从不同的角度来进行总结、提炼、归纳：
针对公司：
随着业务越来越多、功能越来越复杂，微前端可以做到让多个团队同时开发，能够横向扩展出多个团队、组织，使得应用大规模的并行开发成为可能。
针对开发者：
1、可维护性更好 （将复杂的单体应用按模块拆分成多个微应用，每个应用的代码量会很少，不容易产生不可预知的耦合，高内聚、低耦合）
2、开发效率更高（构建速度更快、通过WebPack5模块联邦达到的模块级复用）
3、接入成本更低（技术栈无关）
针对用户：
1、容错性更高（每个微应用都是独立部署、运行时动态集成，一个应用不可用，不会影响其他应用的展示）
2、性能更好（资源共享、解决了使用ifame导致的一些问题）
这几点基本上是满足 MECE 原则的，在讲解的时候就可以从这些方面来说明。
3、认知升华：在讲解的过程中，会和听众交流，产生思想上的碰撞，能让你从不同的角度重新审视所学内容， 进而更为深刻地理解所学知识点。
我们一般在社招的时候不会再招初级开发了，当然，特别优秀的除外。
P6
一般是工作 2 到 4 年的人员，对应我们中级开发工程师这个层级。如果说上个层级的工作是需要在他人指导下完成，那么到了 P6 ，就要转变为完全独立，高质量地完成任务。如果个人有管理诉求的话，还要能带人一起完成工作。你可能会说怎么一下子要求这么高了。看过《斗罗大陆》的人，可以回忆一下，同样是封号斗罗，90 级和99 级之间差距可是天壤之别。在 P5 的时候看到 P6 的工作内容可能会觉得好难呀，担心自己做不到。但其实这个和《斗破苍穹》一样，低级别的人看到高级别人之间的战斗都是“恐怖如斯”，实际上到了那个所谓的高级别就会发现“不过如此”。
这个阶段可能会出现两个问题和两个疑问：
- 只顾埋头拉车，不懂抬头看路。这势必会导致两个结果：每天都在做业务，觉得自己的技术好像没有什么提升；面对浩如烟海的技术，不清楚该学什么。
当自身的技术能力能够满足工作的需要时，很多人可能会想为什么上级每次给我分的都是些没有技术含量的活。此时的你要做的是去发现业务开发中的痛点，想办法通过工具或者其它一些手段减少复制粘贴等重复性的工作，提升开发效率。在解决业务痛点的过程中学习所需技术。平时在学习技术的时要理解某项技术的原理、运用到的思想以及它要解决什么问题，能够举一反三形成通用的理念，不要将自己的编程能力和某种语言、某个库、某个框架强绑定。抱怨解决不了任何问题，勤加思考才是正途。先前，我认为一个人的能力主要由两部分构成：解决问题的能力和发现问题的能力。一般我们程序员的工作都是在解决问题，所以我们平时一直也都在学习如何去解决。但无论是官网还是博客，很少有资料会教我们如何去发现问题。造成的结果就是大家解决问题的能力相差不会太多，而发现问题的能力却很悬殊。如何发现问题？就是从刚提到的你最不想做的又不得不做的繁琐的工作出发，想想怎么能通过自动化的方式，利用机器来帮你解决。现在，除了发现和解决问题的能力，还需要再加上定义问题的能力，什么是定义问题？简单一句话，就是透过现象看本质。
举个例子，我们一直在写 Vue 组件，那组件的本质是什么? emm，就是函数：传入 props，返回虚拟 DOM(React 或 Vue)或者HTML(Angular)。如果理解了这点，那请再想一想高阶组件(High Order Component)的本质又是什么呢？高阶组件是接收一个组件，返回一个新组件，是不是和高阶函数类似呢？接收一个函数，返回一个新函数。既然组件的本质就是函数，那么高阶组件的本质是不是也可以理解为是一个高阶函数呢！再进一步，从之前的模板引擎 mustache，jade，ejs 等到现在的三大框架，我们想要改变界面上的数据，都是通过修改数据来做的（数据改变了，UI 也随之改变），而不再是命令式地去操作 DOM（ JQuery 时代），这些其实都属于数据驱动 UI 理念的实现。好了，以上解释了什么是定义问题。总结一下，一个人的能力是由发现问题，定义问题和解决问题三种能力综合而成，要均衡发展，缺一不可。
- 这个不应该是我做的，那个不在我的职责范围内，始终给自己设限。
这样的想法很容易导致自己一直处在一个舒适圈中，没有太多的成长，无法把握那些稍纵即逝的机会，最终成为了那个最容易被替代的人。产生这种情况主要有三种原因：
- 不自信（认为自己很笨，做不了）
自信来自于自身的实力，如果不是，那可能有点盲目了😂。不自信的原因根本上是缺少一个足够强的学习能力。学习能力的提升，需要训练自己的思维能力和培养好的学习方法和习惯。网上有很多这方面的资料，找一些适合自己的，并在实践中运用。
- 没有勇气(一堆的未知和不确定，不能忍)；
人类对未知的事物就会产生恐惧的心理，因为它们无法被掌控。大部分情况下，我们的恐惧都是来自于自己的想象，而不是事物本身。要培养自己勇于探索的勇气，凡事都尝试一下，如果真得失败了，最起码自己为之努力过，而不能一开始就退缩。
- 没有利益(又没有多给我钱，凭什么)。
一般薪资的提升都是通过晋升获得的，而晋升不只是需要能够很好地完成当前职级对应的工作，还要拥有做好下一个级别工作的能力，这个能力需要平时在工作中锻炼。拒绝做职责以外的工作，就等于关闭了自己晋升的通道。不要面向薪资工作，要面向市场工作，通过做更多的事来提升自身的能力，让市场来衡量你的价值。 总之，想方设法最大化输出自己的价值，总会有相应的回报等着你。因此，正确的做法就是：领导交给我什么任务，能接的我就都接着，并想办法做好。
- 突然发现做某项工作比较吃力，在努力尝试以后，还不是那么尽如人意；和别人比，我好像没那么多天分，这份工作到底适合我吗?
首先，编程这个工作最依赖思维逻辑，如果很明确地清楚这方面自己不行，或者在工作中经常发现自己会绕不过一些弯儿，对此也没有什么特别的兴趣，完全是为了糊口。那么，我建议，放自己一条生路，退出吧！ 其次，每个人的能力有强有弱，擅长的领域各不相同，如果喜欢技术，并且在努力的情况下能够满足公司的要求，那么即使自己没有太大的天赋，也可以继续做下去。 最后，适不适合这份工作，主要看你在工作以外会做什么，那能看出你真正的兴趣所在。有人会说，工作以外我就是打游戏，追剧，这些都不是我说的兴趣，只是爱好，它不用太多的付出就能获得快感。如果真的是只有这些，那说明你并没有比较大的经济压力。而我说的兴趣则是你喜欢且能靠这个为生的。比如说：自媒体、主播、摄影。如果都没有，那就需要培养出对当前从事职业的兴趣。
- 都说 35 岁是个门槛，技术、技术管理、项目经历、产品经理 or 转行，我该怎么选?
凡是有这样想法的其实都是想在 IT 这行做下去的，选择什么方向都可以。想想自己擅长什么，同时审视一下自己的内心，真正想要的是什么。对工作的兴趣和完成工作后取得的成就感是最好的内驱，会让你在这条路上走得更好更远。如果没有什么自己的想法，我推荐是走技术管理这条路。因为这些路走到后期无论是主动还是被动都需要做管理方面的工作，既然都要做，为何不从自己熟悉的技术做起呢？而且，管理本身就是人生的必修课，你总得管理一下自己吧！因此，职业的发展一般需要两条腿走路，即：专业(P) + 管理(M)。有些人特别清楚自己想要什么，可能就是不想做管理，也没有问题，阿里很多高P也是在做纯技术，不过做技术的思维要向管理看齐。
P7
对应我们高级开发工程师这个级别，大概是毕业后 5 年左右。这个阶段要求我们不仅要在技术上有一定的深度，能够进行中小型系统的架构设计，解决领域内出现的一些较为复杂的问题；而且还要在团队管理方面花费更多的精力，保证项目开发的成本、进度、质量，并形成人员梯队做更多更有价值的事情。这个时期可能会出现四个疑问：
- 每天都在做一大堆“杂事”，编码的时间少了，技术退步了怎么办?
既然已经做了管理，首先要认可管理的价值，否则很难做好。 **工作的本质是解决问题，一个人解决问题的能力再强，由于精力等各种原因所限必须要依靠团队才能创造出更大的价值。**管理要解决的不是一个人的问题，而是一群人的问题，因此管理岗比执行岗的薪资高，也是理所应当的事。在认可了管理的价值，觉得做的这些管理工作不再是杂事后，再来看技术退步的问题。技术管理者和普通开发人员的角色发生了转变，做事方式由原来的被动执行（给什么任务就做什么）到主动工作（从想——如何提升团队的开发质量、效率；如何进行人才培养，到做——落地实现）。关注点也不再一样，普通的开发人员更关注技术的实现，而技术管理者需要考虑的是技术的应用，比如做什么，要不要做，能不能做，值不值得做。以上这些决策性的工作，依赖的是技术的敏感度和判断力。那怎么样能够快速提升这方面能力呢，主要有两种方式：a.与大牛沟通(提升视野) b.安排下属学习，听取汇报(扩充知识)。与此同时，自身也需要利用更多的时间来学习，让自己成为“T型人才”，集知识的广度（美貌）和深度（智慧）与一身。针对前端来说广度就是跨端、跨栈，深度就是性能、安全、动效、二三维。当然最好是“π型人才”，集技术、管理于一身。
- 我看某某管理得挺好的，可自己好像又学不会，怎么办?
每个人的性格，沟通方式都不一样，导致管理风格也会不拘一格，不用强求必须和某人的一致。管理方式上没有对和错，只有适不适合。这里多插一句，有的人觉得某个人在专业或者管理领域内特别强，就会学他的方方面面，包括一些不太好的习惯，比如：说脏话。而且内心还笃定：这么厉害的人都说脏话，那说脏话也是没错的。人非圣人，孰能无过，务必要坚守住自己的价值观，取其精华，去其糟粕。
- 我的下属技术能力比我强，我能管理他吗?
很多做管理的人会有这样的顾虑，因此在人员招聘的时候会刻意招一些技术不如自己的。如果每个层级的管理人员都这么想，就会导致团队人员的技术能力就像俄罗斯套娃，一级不如一级。
曾有人做过比喻：技术人员就像是拉车的马，而技术管理是车夫。**两种不同的角色，不仅没有任何竞争关系，而且还是互相成就的关系。车夫看方向，不断激励；马奋力向前，又快又稳。**领导最终看的是整个团队做出的结果，创造的价值。
- 感觉自己在公司已经到了职业发展的顶端，接下来该怎么办?
两个办法：把现在的工作做大，带更多的人；换到更大的可以发挥的平台。
P8
对应我们资深开发工程师，一般工作经历在 7 年以上。这个阶段可能会出现两个问题：
- 缺乏向上管理的能力
TeamLeader 是整个团队的天花板。只有争取到所需的资源，做出成绩，说清贡献，让领导放心，进而得到领导的信任，才有可能获得晋升，才能拓宽整个团队的发展之路。要解决这个问题，需要从两方面着手：认识到向上管理的重要性(和管理一样，都是把认知放到第一位，因为不同的认知产生不同的情绪，做出不同的行动导致不同的结果)；想办法通过具体的数据来阐述给业务带来了多少价值。当然除了以上两点，同时也需要团队中的中坚力量能够把 Leader 不断往上托。比如：你们把我托到董事长的位置，你们就是 CEO，CTO 和各个部门经理😝。
- 一心编码，不关注团队成长
编码的工作大部分人都可以做，难一点的中高级开发也是可以解决的（有没有给机会），只不过你做的质量和效率会高一点，但也很难达到质变，因此，编码的价值很难高过管理。开发经理这个级别出现这个问题已是不对，如果到了技术总监这个层级还有同样的问题，那么这对公司来说将会是灾难性的。研发总监不仅要对一些项目的结果负责，更要肩负起提升公司技术团队成长的责任。一般情况下，如果不是大厂，技术的实现都不会有太大的难点。如果某些技术只能是研发总监才能解决，说明目前并没有形成人才梯队，需打造一个较为完善的人才培养的体系，通过成就他人来成就自己。
几个阶段可能存在的问题和对应的解决方法都说完了。不知道是否解决了你的疑问呢?最后请你思考一个问题：这个团队因为你而有什么不同？
本文未经许可不许转载，请加 天下布武 (微信 zapzqc) 获得授权，否则在知乎、公众号等平台直接转载，尤其是裁剪内容后转载，都会直接进行投诉处理及不尊重原创的曝光。
