出于写这篇文章的目的，是因为我觉得一个5-6年程序员都会有的一个痛点，或者说是转折点——职能管理or 技术架构。
至今也算是快6年的程序员了，目前带着算是6-7号人的一个核心team，也将近快1年了，虽说3年前形式上也算是个leader，但也只是体现在项目上的主导，很大程度上我当时的领导只是觉得技术过得去，靠谱，主观能动性强这个层面上，所以，还没有真正经历到一些leader应该有的境遇。当然，快一年了，也应该有很多的感悟，在此跟各位分享下（当然也避免不了槽点，见谅~ ;) ）
首先讲到职能管理，说白了，这个岗位考验的是你的情商。在大厂，用我当时老大的一句话，你需要抬头看天，然后再是去想怎么走好路。字面意思就是，你应该要知道你的顶头上司想要什么，你就要替他考虑想到做什么，然后你还要去想怎么做好这件事。话虽然那么说，但其根本还是很有讲究的，就互联网这个行业，程序员是一个“非量产”的工种，尤其在这人员流动性极大的年代，需要人性化管理，对你在领导的角色来说，既要有威信，又要不失人心，对于你在下属的角色来说，你要时刻替老大着想，揣摩老大的意图，而且，随着老大的职位越高，你的沟通方式越是得讲究，这里举个例子，部门经理有半小时的时间听你汇报，有半小时的时间对你说教，往上总监级别有十分钟的时间听你汇报，有五分钟的时间对你说教，那么再往上VP(副总裁)级别也许就三分钟的时间听你汇报，一分钟的时间对你说教；假如你带5人左右，你每天时刻可以去跟他们交流了解他们，带10人左右，你每天每人花5分钟的话就需要1个小时去了解他们，带50个人，你还是这样去交流的话，我估计你就不用干别的以外的事情了。由此你可以看出，对你的总结能力，领悟能力，表达能力都是随着职位提升而要求更高。
看完了上面的话，你觉得你乐于去琢磨这些事情，并且你认为你可以做好的话（HR对职能管理好的定义:在保证员工的离职率在一定的可控范围内的情况下相对同级别部门的KPI更突出），我建议可以往这方面发展，当然你要是做好了管理岗位，说实话工作压力跟强度远远小于我接下来要讲的技术架构。
那么既然后者要比前者苦逼，为何还会有人会去选择这条路呢？而且，LZ目前也正在往这条路上去...再这里，请容许我吹个牛，我自认为，我的team还是管理的相当不错的，第一，相对于别的team还是很稳定，第二，我们的产出我们的效率是同级别team里最高的，而且我们的系统要求也是最高的。怎么样才能做好职能管理呢？留给大家思考...跑题了，我这里想说的是为什么要选择这条路？很多人也许会说不想搞那么多烦心事，安安静静写代码，这当然也没错，但是这只是说明有一部分的同行性格所致，但是不包含一部分并不是，原因很简单，职能管理始终要去看“天”，揣摩领导的意图，而不是真正去做好一件你认为应该去做的事情，还有更重要的一点，当你觉得你不会给人打工一辈子的话或者说你需要靠这个职业这个行业给你带来“更多”的话，那么你需要突破瓶颈。在这里，我想提到一位我的好友，他的学校，待的时间最长的公司都并非是一线，但是他自己一直怀揣着自己的梦想去努力，这里不说空话，举个例子，他也是业务系统出身，但是所用过的技术框架涉及到的基础都很精通，这也是为什么前段时间有一篇文章《做业务系统如何成长为架构师》来介绍如何具体从业务系统转变架构师之路。目前他有拿到国内一线互联网的OFFER，而且还不乏基础架构部门的高级别offer，级别算是在总监级，这里就不方便透露了。
我也想说，他到目前为止算是我的贵人，因为在遇到他之前，我一直是迷茫的，困惑的，我看不清我技术的路，但是我发现技术本身是能够给我自己带来“更多”的时候，我的眼前突然明朗了。
在此，看到这里的人都是真爱，感谢你们~博客写的不是很勤，也希望能多写博客，提升下自己的表述能力，能给带来同行们的参考~