数据人如何提升自己
程序员和金融是当前社会里唯二的高薪水岗位，努力一把，每月几万收入都不是什么问题。很多人拿程序员和医生、律师作比较，其实是不同的，医生、律师的经验可以复用，年纪越大，经验越多，收入也就越高。但程序员和金融民工，很多时候，学习的技能更新换代很快，需要不断的学习新知识，才能跟上时代的步伐。
|0x00 学习能力如何成长
1.工具使用的熟练度：为什么工具使用要放在第一个呢？我们知道，写代码其实只占用了日常约一半的时间，还有一半的时间在Bug的修复和问题的查找上。如果你能够熟练使用开发工具，别人找一个Bug或者修复一个问题需要1小时，你只需要5分钟就可以了，那么你的效率就是别人的12倍。天下武功，唯快不破，在程序开发中，效率决定了一切。
2.书籍与文档的阅读：程序的知识是一个系统性的框架，不是单独看一篇文章就能明白，也不是刷一遍文档就可以理解，既需要看原版文档熟悉知识，也需要多看书籍理解背后的设计思路。当然，由于历史原因，绝大多数的文档和书籍都是英文的，需要下一定的苦功夫来阅读，但时间长了以后，随着阅读速度的提升，你能力的提升也就比之前高了很多倍。
3.参加行业会议：不论是工具使用，还是文档书籍学习，都能够让我们深入了解某一项技术，但是对于业务的全貌理解，还是不够的。如果有可能，应该多参加一些行业会议或者技术大会，或者阅读一些相关材料，像Spring等，能够在单位时间内，集中讨论一个问题。当你沿着一个问题由浅入深的了解下去之后，你会发现，对于技术，你得到的不仅仅是经验的提升，更重要的是兴趣的积累，让你能够更有动力去持续的研究下去。
4.多做项目、多看源码：仅仅学习是不够的的，还需要配合实践的过程。在项目中我们可以尝试一些新的技术，可以通过写demo的方式快速的了解某一些项目的原理。写一个demo可能需要1个小时，但它给你带来的直观印象，是很长时间内遗忘不了的。另外，看源码也是一项非常重要的技能，至少能够了解优秀程序员是如何思考和编写代码的。同时，对于底层运行的一些细节，也有很大的帮助。当然，看源码是一项非常浪费时间的事情，但有一些必要的源码，还是要抽时间去阅读和理解的。
|0x01 技术能力如何成长
1.Coding能力的提升：前面提到了，学习能够很快的推动你经验的积累，但是转化为实际技术能力的提升，还需要大量项目的练习。虽然LeetCode能够教会你如何写一个算法，但是完整的实现一个项目，给你带来的提升还是非常大的。很多技术新人在初次面对大规模并发、批量上线、海量Bug、CodeReview、秒杀场景等情况下，会出现很大的不适应心理，写起代码来畏手畏脚，其实都是不熟悉导致的正常现象。这种业务会推动你去解决各种非常实际的问题，也让你去学习更多平时意识不到的技术，比如Java中多线程、反射等场景。如果系统性能要求非常苛刻，你还需要去学习JVM的底层原理，以优化那些看起来非常繁杂的代码。可以说，Coding能力的提升，都是项目逼的，但这也是最快的提升路径。多一次内存崩溃，你就对GC行为多一份了解。在Coding的过程中，对于知识的深度，要求比较高。
2.架构能力的成长：说起架构，大家的直观理解都是各种的流程图、框架图、结构图等，看起来非常的简洁明了，似乎每个人照着画个类似的图，也可以当架构师。但是，实际的困难永远是隐藏在图片后面的，你很难理解图上的一个方框，为什么要用这种框架，以及为什么要放在这个位置。当程序员从初级走向中级的过程中，一个最大的变化，就是原先被动接受的需求，开始变为主动的跨部门沟通，一个标准的项目，至少要跨三个团队，怎样设计好整个框架结构、怎样定义数据的模型、怎样对接各自的接口，都是一些细碎但是重要的事情。尤其是异地多活等项目，当参与人数上升到一个数量级时，每个人都需要看懂整个架构，才能明白自己应该做什么。一个好的架构，需要根据实际业务的情况，来突出研发的重点，确保几个最关键的问题如何解决。在数据开发中，如果不能够设计好整个流程，最直接的影响，就是数据的准确性受到比较大的挑战。在这个过程中，架构的学习，对于知识的广度，要求比较高。
3.思考问题的深入：通常而言，技术人员思考问题有三个阶段。第一个阶段是“能用”，不论怎样的需求、不论怎样的编程语言，首先把demo跑起来最重要；第二个阶段是“会查”，当项目的代码数量开始不断增长时，所面临的耦合内聚等情况变多，以往写过的代码会出现隐患，系统之间的关联会出现问题，代码的Bug数量也就随之提升，如何快速的思考问题产生的原因，如何准确查到问题，决定了你项目开发的周期；第三个阶段是“要懂”，解决Bug，最重要的是避免写出Bug，优秀的程序员，很多时候不需要画出什么架构图，只需要拿出一小段代码，举一个简单的Case，大家都可以明白。懂一个项目，理解程序语言的运行原理、理解开源框架的设计思路，能够让你在项目开始前就理解可能出现的问题，并在第一次写的时候就避免这些坑。说来说去，原理性的东西，是每个人最难遗忘的东西，但掌握原理的过程，是没有捷径的，是需要通过1万小时理论逐步积攒出来的。
|0x02 偏业务与偏基础的选择
每个程序员，在技术达到一定的阶段之后，都会面临一个方向的选择，那就是偏业务方向，还是偏基础技术方向。以数据为例，一部分人需要承接日常建设数据仓库、应对产品需求的任务，对SQL开发、数仓理念、产品模型的理解要求很高，这种情况就是偏业务方向；另一部分人需要搭建对应的Hadoop平台，优化MR/SQL的运行，优化开源框架，或者是偏向机器学习、人工智能的算法研发，这种情况就是偏基础技术方向。
1.偏业务的思考：偏业务的方向，比较建议针对某一领域，持续的投入精力，这样对于自身业务的发展未来会有比较好的预判，能够意识到数据产品背后的商业价值。同时，对于复杂业务逻辑的抽象，也是搭建数据仓库的一个非常重要的前提，这其中需要用到很多方法论与建模知识。最后，在数据仓库搭建的过程中，对未来业务的变化，也需要留下一定的改进空间，因为重构永远是偏业务同学最头疼和最花费时间的事情。
2.偏技术的思考：业务通常是能够实现的，但技术不一定，对于自己研发方向的基础性技术，要有一定的预判性，防止业务发展受到基础技术缺陷的拖累。此外，基础技术需要多看、多学，对于业界的技术发展方向要有自己的认知和判断。最后，就是多练了，对于自己领域的基础技术，要有非常好的技术深度，才能应对可能出现的各类问题。
|0xFF 如何做一名合格的TL
工作五年以后，随着技术的完善和成长路径的清晰，很多技术人接下来就要面对TL的问题了。TL就是Team Leader，团队管理者的意思。互联网公司的技术管理通常有两个方向：负责技术和负责团队管理。传统公司的TL更多的是负责任务拆解、项目进度预估及风险控制等方向，而互联网公司由于项目的长期性，不仅需要对业务有一个清晰的认知，还需要对于对应的技术有长期的联系和了解，能够帮助团队在遇到瓶颈时跨越大山。
彼得格鲁克说过：“组织的目的，是让平凡的人做出不平凡的事情。”一个团队发展的怎样，很大程度上取决于TL的管理方式。马云说：“人才的离职有两种情况，一种是钱没给够，一种是干的不爽。”后一种，就是TL所面对的直接挑战了。那么如何做一名合格的TL？
1.团队建设：团队通常会存在两种比较常见的问题，一个是业务配合不规范，一个是跨团队协作混乱。业务配合是重中之重，如果每个人都采用自己的习惯来写代码，那么其他人在维护的时候，通常都比较头大，一旦人员离职，交接的成本也非常高。因此业务配合是首要解决的问题，主要就是在流程与制度上。例如，技术的开发要有规范，定期CodeReview以统一开发思想；开发、上线、运维，要有明确的负责人，避免出现问题无人负责；与需求方对接要有明确的PRD或者需求文档，按照流程协作，避免后期出现了问题被Diss。其次，针对跨团队协作的情况，由于需求变更快、责任划分不清晰，会极大的损伤团队的积极性，至少在团队内部，TL要能够帮助大家进行需求的统一管理和分派，避免成员收到外部过大的影响。
2.团队管理：团队管理通常有两种风格，一种是集权式的风格，定义清晰的工作目标，并且把任务分解的非常细致，团队成员能够按照计划一步步推进，以过程为导向；另一种是放权式管理，只定义一个大的目标，做关键性的决策，但并不深入每个细节，不管控团队成员的具体行为，以结果为导向。两种方式没有对错之分，当业务流程比较清晰，骨干员工能够很快的领悟业务并主动开发时，推荐放权式的管理。但如果团队刚刚建立，流程与制度没有完善，开发的流程也没有跑通的时候，推荐集权式的风格，让团队尽快的有序起来。
3.团队文化：团队文化是一个非常软性的指标，但对于结果却有着比较大的影响。例如，在以KPI为导向的公司里，很多人为了避免故障，就不会主动的重构代码，就像一句笑谈：“没有上线，就没有故障”。再例如，很多员工时间长了以后，积极性会下降，很难主动去承担更多的责任。在不好的氛围影响下，优秀员工会被排挤，团队的向心力也很难聚集，离职率也就居高不下。因此，从TL的角度出发，发挥自身的人格魅力，尽可能的为团队树立榜样，很重要。这里提出五个建议：坦诚、公开、透明；平等相处；团队关系和谐；主动承担责任；乐于分享。
4.沟通辅导：我们平时的工作中，沟通占据了相当大一部分比例，以数据开发为例，大约50%的时间都在各种沟通上。但在程序员群体中，能够主动沟通、或者是高效沟通的人，非常少，很多人非常不善于表达自我。作为TL，最有效提升团队沟通水平的方式，就是一对一沟通。建议找一个比较私密的环境，定期与团队成员做一些沟通，用心倾听并切实解决员工的问题，在一些比较迷茫的问题上给予自己的建议和引导。或者，定期举行团队沟通会议，不谈工作的内容，只谈生活和想法，也能够很好的建立沟通氛围。如果都学不会，那就团建吧。