关于程序员的发展方向

     出于写这篇文章的目的，是由于我以为一个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，级别算是在总监级，这里就不方便透露了。

　　我也想说，他到目前为止算是个人贵人，由于在遇到他以前，我一直是迷茫的，困惑的，我看不清我技术的路，可是我发现技术自己是可以给我本身带来“更多”的时候，个人眼前忽然明朗了。

　　在此，看到这里的人都是真爱，感谢大家~博客写的不是很勤，也但愿能多写博客，提高下本身的表述能力，能给带来同行们的参考~