作为新手程序猿，首先要清楚的认识到，从什么开始做起，才能让自己觉得， 工作，是一件非常开心的事情！
作为技术工程师，能选择作为职业方向的也不少，比如：
每一种角色，平时的工作状态必然都是不一样的，通过写码得到的成就感也是不一样的。
作为一个新码农，如果你希望自己写的代码， 能最直观的变现成用户看得见摸得着的东西，因此而获得工作上的成就感，并且因此而爱上这份工作，那么选择Web前端工程师或者客户端工程师，定是较好的。
倘若你更希望每天通过命令行，在线上各个服务器之间跳来跳去，并且 敲一堆别人看不太懂的命令，写一堆别人看不太懂的脚本，并因此获得成就感，感觉更具有 高逼格，那么选择运维工程师，一定没错了！
一些刚毕业的学生，很有必要在投简历求职之前，搞明白自己想做什么；当然，也有大部分学生是通过校招进入到公司的，具体进去以后做什么，可能都是公司随机进行分配；对于这一部分的同学，如果在入职后一段时间内无法在工作上找到兴趣点，就真该考虑申请 transfer到其他Team了。
工作不应该仅仅是是挣钱养家糊口的一个工具，更应该是做人做事、成长道路上的一种乐趣。做自己喜欢的事情，再辛苦，也值得（切莫误解：不是推荐大家加班，哈哈）。
沉淀，是能最直接证明自己有收获的一种方式，可以是文档沉淀、技术沉淀，等等
工作过程中，我们肯定会去做一些技术调研、方案分析与评审，这些东西便可以细细整理成文档，统一汇总到一个地方（比如团队的wiki专栏下），自己能去review，组里其他同学也能查看到。
在一些大项目开展过程中，或多或少会针对某一类问题创造出比较优越的解决方案，可能是一种高性能的实现方式、也可能是一种高效率的调试技巧，这些东西，稍微花点心思，都能将其作为一个类库或工具提供给组内其他同学，以此作为技术点，沉淀下来。
简单来说，可以把握这样一个原则：
能用 文字记录的做事方式方法，就一定不要只靠口口相传！用嘴巴传来传去，慢慢的也就走了形了，俗话说的好，好记性不如烂笔头！
好用且实用的技术实现方式，能抽取成 组件或类库的，就尽量让它最大限度的复用起来，并伴之以尽量详细的使用文档！切莫针对类似的功能，在组内还不停的造轮子！
多看多写多调研（有时候需要以玩儿的心态去学习）；但做技术的，若无实际产出，那只叫瞎折腾，知其然而不知其所以然，效果并不佳
就我个人而言，无论是在 百度，还是 美丽说，所有我能够去沉淀或者帮助大家一起去沉淀的东西，一定都不会放过。
如 文档方面，我们搭建了团队专属了文档平台，有项目设计与实现方案的评审文档、有项目总结的分享文档、有大型项目的排期节奏跟进文档、有技术的调研文档、有团队技术分享的文档、更有团队周报的归档专栏等等。
在 技术方面，有符合团队开发规范的集成解决方案、编译工具、开发工具、前后端线上服务监控与报警系统、后端服务性能监控与分析平台等等。
在 玩儿技术的这一点，比如 Web前端助手(FeHelper)就是在百度做前端的时候，玩儿Chrome扩展，一步步沉淀下来的。记得当时CSDN还举办了一个Chrome浏览器插件开发中国区大赛，这FeHelper也迷迷糊糊拿了个三等奖。
再后来微信公众号兴起，在朋友圈铺天盖地的转发都是只有一个标题，很土；正碰上那一段时间 2048小游戏在PC和Wap上特别火，于是我也写了一个放到自己公众号，本着让大家一起能够在微信里玩儿起来的心态，于是搞了一套基于微信公众号分享的SDK，应用到这个小游戏里；这就是大家后来一直在使用的 WeixinApi。在微信一直没有推出官方版的js-sdk之前， WeixinApi造福了许多人。
任何形式能让别人看得见摸得着的东西，才叫做沉淀，更是可以用来衡量价值的参考。
接受Leader的命令，并能单枪匹马的把产品功能做完上线，这顶多能够算得上 能做事，离 会做事、 懂做事还差得远
如果有一天你觉得自己能够独当一面去负责一个产品功能，不再需要导师和Leader的协助，那么，是时候从更全的维度去历练自己了： 主动挑起一个项目，作为项目负责人，将其推行到底！
你至少可以从这几个方面，得到更多的收获，找到更多的成就感：
分析需求，判断该项目需要涉及到的相关角色
组织各角色进行项目需求评审，并分析产品功能上的技术可行性、时间成本等
对需求进行功能模块合理拆分，落实前后端工程师的工作范围
组织前后端工程师进行技术方案评审，并结合需求指定的上线时间判断是否需要分优先级分批次开展
合理分工，产出研发排期，并汇总联调、自测、以及QA的测试工期，统一输出项目的排期
跟进项目进展，结合排期Review项目产出，及时发现风险点，及时调整并通报
较大的项目，更有必要组织定期的站立会，以确保项目整体进展顺利
项目过程中有临时新增需求、或需求变更、或技术实现方案调整，更要能条理清楚的与所有角色进行分析，放眼大局观，结合项目的整体上线要求，输出最终的调整方案，保证项目稳健开展
测试前期，需要和QA明确其中的核心测试点，对于技术实现较复杂的地方，需要明确告知测试的力度，以免测试用例覆盖不全
项目上线前，需要与运维工程师完成一切线上环境部署与配置，确保项目上线毫无障碍；对于涉及到边缘产品较多的项目，更需要考虑到灾备预案情况
项目完成测试后，如果是较大的产品需求，需要和产品同学讨论，是否进行公司内部体验，或者线上小流量（灰度）测试；并提供合理的问题反馈渠道，收集并整理用户反馈，快速优化
项目上线后，需要密切关注服务稳定性，关注用户反馈，稳定后，能进行项目上线通报
组织项目组所有角色进行项目总结，分析各角色在项目配合过程中出现的问题，总结经验教训；同样也记录项目中良好的问题处理方式，最后将项目总结分享到团队；以此结束整个项目！
枪打出头鸟，只要你是带头大哥，项目出现任何问题，Leader必然都会唯你是问，整个项目过程中，必然是会产生压力的！但是，如果你永远都不敢迈出这一步，又怎能知道自己能力究竟有多大呢？
所以，大胆去做吧，团队一定都是更喜欢 敢于主动挑起责任担子的人的！
将所有成熟的工作方式，倾囊相授，也从新人身上做自我反省
优秀的做事方式，应该得到传播， 让更多的人花更少的时间去变得优秀。工作中，最好的方式，就是在自己成长以后，做一个导师，协助新人一起成长，比如：
结合新同学的工作能力、业务范围、技术兴趣点，一同分析Ta成长过程中真实存在的阻力（或盲点）
为新同学量身定制短期、中期、长期的成长规划，定期Review成长得失，及时纠偏
带着新同学一起去尝试一些大于Ta现阶段工作能力的事情（业务功能、技术Topic等），帮助新同学挑战自己，逐步突破自身的能力极限
学会放手，做好引导和后备支撑，让新同学完完整整的去搞定一件事；栽了跟斗也不要紧，任何人成长的过程中都应该经历一些坎坷；不经风雨，又怎见彩虹？
引导并督促新同学进行文档和技术各方面的沉淀，协助新同学在团队里找准自己的定位，站稳脚跟
引导新同学学会分享、学会与其他角色的沟通技巧、并逐渐学会把控项目的全局观
当然，你也需要从新人成长的过程中，不断的反思自己，新人做的不够好，是我的原因吗？新人做的很好，我有功吗？
新人某个功能没做好，是不是自己没有提前Review他的项目实现方案？或者自己给他的方案本身就是有问题的？
新人某个项目Delay很严重，是不是自己没有多去Review他项目的进展？或者自己也没搞明白项目的上线计划是什么？
新人某个项目Bug太多，是不是自己没有尽到一个导师的指责，为他做好Code Review？或者自己平时的项目就是Bug频出，新人只是效仿而已?
新人在其他角色面前总是沉默寡言，是不是自己没有告诉他，应当大胆表达自己的想法？或者自己也不敢在人前多说话，自己也怕被拍？
新人在与其他角色沟通过程中，冲突不断，是不是自己没有教给他更好的沟通方式？或者自己也不会与人沟通，自己也经常与其他角色闹得不愉快？
新人用一些很巧妙的方法把某件事情完成的很漂亮，得到大家的赞许，是不是自己给了他很好的引导？或者从这件事上面，你发现自己也有不如新同学的地方，你们需要互相学习？
新同学主动找你一对一沟通，进行成长总结，自我批评，这又是不是你平时的做事方式，让他学会了积极领悟？再或者，你需要思考自己是否具备这样的一个主动性，以及能够批评和自我批评？
你对你的新同学足够了解吗？你对自己足够了解吗？
一个好的导师，永远都不要担心 青会出于蓝而胜于蓝，因为这是好事，这是他的能力，更是你的本事！他若真能胜之于蓝，说明他足够优秀；我们要学会与优秀的人在一起，那样才能更快的成长。
技术的革新都是非常迅速的，我们绝不能仅靠项目上的产出来充实和提高自己；码农界聪明的人太多，必须把好的技术思想都吸收进来
逐渐的，需要将自己视作一个技术负责人。当然，若条件允许，可作为团队技术负责；若团队各方向划分较细，可作为某业务方向技术负责人。
多分析团队工作上遇到的一些技术难题，总结并归类，互联网行业发展至今，你所在团队遇到的绝大部分问题，在别的公司必然都经历过了。跳出来，想方法从各渠道了解发展较为成熟的公司、较成熟的技术Team都在用过什么样的方式来解决这一类的问题；虽然不能照搬照抄，但最起码能从中得到更多的启发。
新技术更新的很快，尤其在Web前端方面，不过多久就又出来一种新的解决方案。你应该作为一个技术痴迷者，密切关注行业的动态，看看人家都在搞什么，为什么会出现这么多新的框架、类库、工具等。举个例子，搞明白：
在没有 jQuery之前，大家用原生的DOM也能把功能开发的很好，那为什么会出来jQuery？它是为了解决什么样的问题而出现的？用它与不用它，在项目上会有什么不一样的地方？
jQuery已经很好用了，那百度WebFE以前为什么还要在公司内部搞一个 Tangram？是单纯的造轮子，还是因为它的确可实现各种Api定制化打包？对于jQuery的老手，如果使用 Tangram，会有些什么不一样的地方？
后来大家又一致吹捧的 AngularJS、 Backbone.js、 Ember.js这些又是什么鬼？都是哪个公司哪个团队基于什么样的问题才造出来的？他们用这些工具只是因为某一个产品功能，还是说这货可作为一类通用的解决方案而存在？倘若要把它们引进到自己的项目组，是否真正适用？你能从中得到什么启发，大家又能学到什么？
Nodejs为什么会出现？ io.js为什么又会作为其分支，单独发展？后来为什么又还是merge到了一起？
再比如跨平台的移动开发工具， PhoneGAP、 Titanuim、 Xamarin、以后今年火起来的 React Native，为什么解决同样问题的东西，会出来如此多，更新如此的快？最后出来的东西，是否都已经具备了 先辈的优良品质？它们所针对的用户群体是什么？为何能得到大众的青睐？它们和原生Native有何区别？
PHP 7都发布了，为什么你们先上服务还在使用 PHP 5.3.29？升级PHP到最新版，在代码上是否需要做些兼容？开发上是否和以前有变化？带来的性能提升是否可大幅度减少服务器的数量？
全文的搜索引擎， Sphinx和 Solr都是啥？索引的效率、搜索的性能、对中文分词的支持、以及对实时索引的支持，这些维度都有什么不同？如果项目上需要使用，结合实际的需求，选择哪一个更为合适？
再比如，你的团队需要对线上服务进行多维度监控，市面上已经存在的 Zabbix、 Nagios、 Open TSDB、或者 Open Falcon，是否都知道这些东西能监控到那个层级？线上部署与应用的成本如何？后期的水平可扩展性又是如何？假如你要自己写一个，你能否先画出一张清晰的监控布局图？
总之，闲暇的时候，把技术眼界放宽些，多逛逛 Github，或者一些国内外牛人的 Blog，看看别人都遇到了什么问题，都在解决什么样的问题，多做一些假设： 如果这个问题是你遇到了，你会怎么做？
公司不是养老院，发你工资，你就必须创造价值。任何一份工作（一个产品功能、一个技术系统、一套开发规范、抑或一套工作流程）都必然有它的问题所在，多思考多分析，发现问题并解决问题，这样才能创造价值，我们也才能成长！
也许你所在的团队就好比一坨浆糊，一团糟，同事们都已懒得抱怨，只在乎工作能干完上线就成。也许你所在的团队一切都顺风顺水，同事们一团和气，工作之余有说有笑，开心的不得了，甚是满足。
但是，世上没有100分的人，必然也没有100分的团队；凡人皆有缺点，团队亦然。不要被乱七八糟的团队吓到，也不要觉得团队看起来太好了，便无从下手！
大家平时的开发方式是什么样的，是否都在重复的做一些体力劳动？如果是，是否可通过 开发一些工具来自动化完成？
如果每位同学都自成一套开发体系，这样的代码必然是很难维护的，团队里旧人去新人来，看着各式各样的代码，哪有不抱怨的理？在 开发流程和规范上必须要有统一的标准，推动并协助切实执行！
一个线上的技术系统，是不是都因为它是一个庞然大物，不敢轻易调整，所以对于新功能都是不断的打补丁？久而久之，团队里的每位同学必然都只知道补丁，而不知道它真正的功能，真正的工作原理！所以必须要迈出第一步 牵头去重新梳理、归置，将核心的部分独立出来，展现它应有的功能！并伴之以详尽的文档说明！
对于一个臃肿的业务系统，是不是大家都因为已经习惯了现在的开发、测试、部署等方式，所以不愿意去 做纵向拆分？如果这样的一个系统已经拖慢了工作效率，那就必须动手梳理整治，让它变成多个功能独立的子系统，小而美，业务分明，项目之间更不易产生冲突，可维护性也能大大提高！同时推动团队给每个子系统安排不同的owner！
如果以上技术团队本身的问题不存在，则可以从产品功能的线上服务稳定性着手考虑。线上是否有频繁的报警？各业务日志是否都正常？用户是否对某些常用功能有频繁的反馈或吐槽？总之，能用工具自动监控报警的，就一定不要用体力解决。能够通过工具平台让运营或产品同学自助查询问题原因的，就一定不要再让研发手工去操作。
只要愿意静下心来，从细小的点着手开始分析，发现问题，并利用一切可利用的资源，推动去解决它，不怕事小，只要一件件逐渐积累下来，定能体现出自己的价值，老板们要的就是： 因为有你，所以团队变得更好！然而，你这样的收获，是无法简简单单只用金钱就可衡量的，更是别人拿不去的财富。
当然，这也不是每个人都有这样的机会能被提升为Team Leader；工作上可没有裙带关系，哥儿俩感情好就把团队也交给你；必须是你平时的工作已经能充分证明，你具备了带领这个Team一起发展的能力！
当然，在我看来，更重要的是做事，而不是在行政位置上的那个Title；只要你现在正在做的事情，就是带一个团队，至于是否是经理职称，根本不重要。有时候一个小公司的技术总监，到了大公司，也得老老实实的做一线研发，不是吗。你若真牛逼，公司又亏待你了，你走了，那只能是公司的损失。所以，还是老老实实的做事吧，该来的自然会来。
作为一个业务&技术团队的管理者，至少需要做这些事情：
按照团队所负责的各业务进行清晰地规划， 切莫吃大锅饭，还是小团队作业的好；一支精锐的部队，责任感会更强，每个人会更清楚自己要做什么。
每条业务线， 需求范围明确，跨部门的需求，必定要有清晰的界限，保证组内各Team的工作能更顺利开展
组内各小Team必须有 统一的开发规范，攘外必先安内，如果自己Team内部的开发规范都一团糟，提供给第三方部门的接口还如何统一？
组内各小Team必须有 统一的项目全流程，在每个环节都应该注重实实在在的产出（沉淀）
组内需要沉淀公共的组件库、类库、公共服务层，它必将形成一个团队的主心骨，绝大部分的开发工作都能围绕着它转。如果有一个需求，团队里任何人 不需要思考，直接就能完成，那就够了。
一个大于10人的团队，必须考虑有效的梯队建设，各方向的业务&技术负责人培养
在各业务方向上培养小组负责人，并让该负责人培养自己的Backup
在团队内培养技术方向负责人，源源不断在团队内输出更多可供选择的技术方案
团队内形成良好的导师制度，Leader带方向负责人，方向负责人带一线研发；同时也需要将梯队扁平化，打造一个无障碍的沟通和汇报机制
有团队周例会制度，每周至少保证有一次机会，能让大家聚集在一起，知晓团队过去一周的项目整体状况，以及下周的工作节奏
团队内部必须形成良好的技术分享机制，至少每周一次，可以是大型项目的技术实现方案分享与评审、可以是大型项目的项目总结分享、可以是项目上某技术点的深入分析与应用介绍、可以是某工具平台的构建思路或工作原理分析、可以是工作中必备小技能（奇淫技巧）的发散讨论、也可以是行业前沿技术的调研报告分析、也可以是一些新技术的尝后感、更可以是跨团队甚至跨公司的技术交流。总之，需要让大家切实感受到：在这个团队，有东西可做，有东西可学！
与同学们进行不定期的一对一沟通，助其排忧解难，有问题也要直接指出来，并授之以渔！帮助同学们成长，这是做导师做Leader的职责！
明确合理的奖惩原则，公司不养闲人，也不养不长进的人；与优秀的人一起，团队才能健康可持续的发展
不定期进行团队建设（Team Building），可大可小，需要创造一些条件，能够让大家能够聚在一起，讨论一些工作之外的东西。身心愉悦了，哪还怕代码写不好？
做Leader的，无论哪个Level，就应该想着：你何时才能把自己现在正在做的这些事情，都交给自己的Backup？
只有你自己能完全从团队现在的事情上抽离出来了，你才有机会去考虑对团队来说，更多更重要的事情，这是给Backup的机会，也是给自己的机会。
俗话说，技多不压身，用更多的技术知识来武装自己，真有一天要上一个陌生的战场，那也完全不在怕的。
当然，技术工程师成长过程中，全栈并不是必须要走的一条路，不过在深入掌握其中一门技术以后，眼界看得更开些，总是好事。
假设你是做前端的，一个前端Team能完全Hold住了，可以逐渐涉入后端，服务端、客户端，做事的方式其实都一样。不用花心思再去把每一门技术都重新学一遍，只要把该领域内的核心技术摸熟了、其中的工作原理掌握了、与其他领域的区别搞明白了，就够了。
如果自身能力有限，领域，精一门儿足以，用同样的做事方式，融会贯通，其他的技术领域必定不会太难。
回想自己工作的这么几年，先做 Java，再做 VB.Net、在做 C#.NET、接着再做 Web前端，一做就是三年；后来又学 iOS、再转 Android；回过头来又继续带 Web前端Team、再带 PHP后端Team；说实在的，方法对了，事情也就好办了。
