又到每一年秋招的时候了，又有一大批应届生准备步入职场。这是一件大家都高兴事情，不论对新人自己，还是对公司/部门/团队。
我个人的职业发展也不算特别顺利，本来也没有任何资格 “帮” 别人规划。但最近跟不少人讨论发现，把自己曲折的经历以及所感所想分享出来，也不全是一件坏事。
成功很难复制但失败却可学习，所以失败经验也许比 “成功学” 更重要。本文就着重介绍一下自己在职业发展过程中的体会，希望能为新人多提供一些参考 “素材”。
打造自己的核心竞争力
技术是立身之本
找到感兴趣的业务
关注外部效应创造价值
打造自己的核心竞争力
每个人在这个世界上都是独一无二的，变得 “泯然众人” 的原因在于没有想好自己的核心竞争力在哪里。有人可能会说 “我完全没有竞争力，对任何事情都没有特别浓厚的兴趣”，这怎么办呢？其实，并不是我们先擅长做某些事才有竞争力，而是先想清楚自己的竞争力在哪里，然后围绕这个点再做事情。
那么如何打造自己的核心竞争力呢？我所采取的办法就是求交集。观察周围的环境，找到自己独一无二的特点，如果没有特点就对多项技能求交集，不学别人的样子只做别人不做的事情。所以，个人的职业发展路线与其说是规划出来的 ，倒不如说是结合所处的环境不断求异走出来的。
比如说，“专业背景 && 个人经历 && 兴趣爱好” 按这个几个条件求交集，很可能团队中就只剩下自己一个人了，围绕这个点做事情会事半功倍。这是因为工作后跟学校里的状态是不同的，工作后更讲究协作，既然是协作就得想清楚 “我需要别人怎样帮助我【如何借力】，我能怎样帮助别人【自己的价值】”。没有找到自己核心竞争力的同学，容易变得像无头苍蝇一样乱撞，也容易被当成资源来使用，这天帮这个忙明天帮那么忙。
找到了自己的核心竞争力，就找到了自己的事业，所有的事情都应尽量围绕自己的事业来做。
技术是立身之本
在工作的前三到五年，应尽量把技术学到一个无法再深入的地步，这几年可能会非常的辛苦，比如说下班后还要额外再自学 2~4 个小时也是家常便饭。
这样规划是有几方面的考虑在里面的，
5 年以内工作经验的工程师，一般项目压力不会太大，不为项目本身负责，所以会有固定的时间是属于自己的。
工作 5 年左右，随着年龄的增长，家庭方面的琐事也会越来越多，很难腾出完整的大段时间来学习
随着年龄的增长，负责的事情越来越多，技术本身所起的作用占比会减少；而前几年，在学技术上的投入产出比是极高的
技术包含哪些方面的呢？我认为应该全面的看待技术，不仅仅是会写代码这么简单。
算法
口语
写作
健身
这几项我做的也不是很好，尤其是算法和口语，现在想想也是追悔莫及，这两项直接决定了以后可以工作的公司范围，一些大厂或者跨国企业，对这两项都是有要求的。另外两项不太常被提及的是写作和健身，写作能力会直接关系到自己的影响力指数，或者说技术观点的辐射能力，好的文档相当于一个 **7*24 小时的广告位，持续不断的向外输出自己的见解。健身也是非常重要的，我发现很多开发的身体状态都不是特别好，尤其是有多年经验的资深开发者。健身计划应放在整个职业生涯，甚至一辈子**的角度来安排。
我所谓的技术指的是，凡是能仅仅通过自己努力就行实现的事情。所以说技术是立身之本，连自己都控制不好，还怎样做好更大的事情呢？
找到感兴趣的业务
老实说刚入职前几年，我也很痛恨 “业务” 这个词汇的。总感觉搞业务不如搞技术那么纯粹，总是掺杂着一些能说会道、巧言令色在里面。但其实并不是软件行业有技术和业务这一说，甚至医院、学校等这样的机构，也会区分搞业务的还是搞技术的。搞业务的看起来 “务虚不务实”，是因为他们在尝试消除问题的不确定性，剩下的问题都是 “务实” 的问题了。
所以说，从商业角度来看，市场或行业变革风起云涌，问题一般是不确定的、不明朗的、甚至有没有问题都不知道。搞业务就需要有一种能力来拨云见日，探索出一条可行的路径出来。技术和业务只是聚焦在了问题解决的不同阶段。
- 搜集信息：面对不确定的问题，我们得从实际出发，消除一切人为假设；这时候就得愿意把手弄脏，尽一切可能的搜集信息。
- 定义问题：对状况有了一些了解之后，就得定义到底什么才是要解决的问题了，解决不同的问题，会有不同的成本也会有不同的收益。
- 问题拆分：有了问题之后，就需要对问题进行拆分，如何最大限度的把可用资源占满，把问题解决掉。降低成本，提高资源利用率
- 进度跟踪：很多问题都是有时效性的，所以能尽早的把问题解决是很重要的一个环节
- 反馈结果：问题解决完之后别忘了反馈，这个反馈过程可以验证以上 4 个环节中的任何误判。
一个完整的问题解决链路，我认为可以分为以上 5 个阶段，它是尝试解决不确定性问题的思维闭环，自然科学研究中的 “科学方法” 也是沿用了这个办法。
找到感兴趣的业务，就是要找到自己感兴趣的问题领域，我想探索哪个领域，我想解决哪方面的问题。拿软件来说，有些部门做出来的系统是为开发者服务的，有些系统则是为老百姓（非开发）服务的，这是两种不同的业务形态。前者需要对开发者的需求有所了解，后者则要对老百姓的需求有了解。值得一提的是，不论做什么业务，写代码都只是手段。
关注外部效应创造价值
刚开始工作时，我自己都很少关注外部效应，活干完了就觉得万事大吉了。其实写代码犹如搞发明创造，把发明搞出来相当于代码写完，有没有人来用这个发明创造更加重要。空有一堆代码，其实没有任何价值，而这些代码被用起来才有价值。所以价值不在代码里面产生，而是在代码之外产生。
转换成这个思路之后，就不会把思维局限在代码内了，而是如何让代码发挥价值上面。会关注哪些人会用这些代码提供的功能，他们还有别的更重要的需求没被满足吗，除了我的方案别人的方案能更高效的满足需求吗？这样考虑的话，会跳出自身作为技术人员的角色范围，多关注一下为什么要做这件事。
代码的外部效应不一定全部产生在团队外部，也有可能是团队之内。本团队的一些同事，可以从代码中受益吗？我是不是应该补齐文档，多做一些沟通工作，是不是应该让自己的工作被更多的人看到呢？连团队的同事都不知道自己在做什么，更不用说代码的用户了。
结语
本文介绍了我个人在职业发展过程中的一点点体会，有很多点是自己吃了很大的亏才学会的。也有一些见解，可能不太适用于应届生或者刚步入职场的年轻人，但我已经竭力站在相同的起点考虑问题了。我认为在分享方法论的时候，讲自己当时是怎么做的完全没有意义，而是应该分享经验，最后用自己的经验站在起点考虑方案。