1. 效率意识
这里的效率指的是增加工作效率，要持续优化自己的工作流程，让自己用越来越少的时间来完成同等工作量的工作。这个时间指的是实际的工作时间，不是说。原来一周的工作量，我熬几次夜加加班，争取两天干完。NO、NO、NO。我希望大家达到的是实际工作时间。
年轻人不要卷工时，要卷效率。
如果觉得自己干活慢，要主动思考一下有没有办法提升。比如是不是开发工具不够顺手？举个例子，我在学会了tmux+vim+oh-my-zsh这套工具链以后，工作效率大大提升。我曾在这个知乎回答中详细讲过：
这个效率提升，缩减的不仅仅是写代码本身的时间。很多人说vim即使配很多插件还是比不过IDE，这句话在很大程度是对的。但是这只是在比较写代码的时间，我们时间工作中可不仅仅是写代码，还有测试验证、登陆机器查看日志。等等。更重要的是，tmux能复原你的工作现场，任何时候只要连上开发机就能回归到你之间的工作现场，你的思维都能里面复原，而不需要重新整理。
另外对于我们也要自己开发一些工具来提高自己的效率，比如我之前在其他回答中有提到过我会经常写一些脚本来完成一些重复性的工作。比如填写上线工单之类的。
工作本身也有很多值得反思的地方，比如是否有因为返工而导致加班，能否避免？有没有因为前期需求讨论的时候开小差没听讲，导致开发的时候需要和各方反复确认？有没有没有规划好一个需求的执行路径，让没有依赖关系的各方可以并行开始工作。
关于这个议题，你也可以继续阅读我的这篇知乎回答：
2. 复盘思维
我是重度的“笔记强迫症”患者（compulsive note taker），我也把我记笔记的习惯带到了工作中。之前在百度工作期间，内网有wiki，我每次上线完都会自己做一个复盘记录，写到wiki中。记录内容大概如下：本次需求的背景、本次上线的代码diff连接（merge request地址）、本次需求学习到的新东西，走了哪些弯路导致自己踩坑或导致工时浪费。
数据很重要，我们要及时的记录下来。这是我在腾讯工作时，一个前辈告诉我的。后来我也一直以此为戒。比如我做了一次性能优化，降低了多少ms。不仅仅要在当时及时的汇报出来，还要把这些数据记录下来，最好有曲线图，截图存起来。等你做述职报告)，或者晋升答辩的时候。有这些数据和没有这些数据，给人的观感是差很多的。如果我们不及时的记录下来，可能过了半年，日志早就没了，监控系统也查询不了这个时间的变化曲线了。这些性能优化的方法也要一并记录下来，这些都是你的财富，你离职的时候不能从公司带走代码，但是这些经验你都可以带走。不然总是稀里糊涂地做项目，半年一年以后什么都没积累到。
除此以外，我还会我在公司内学到的业务知识、技术知识（比如我看过的源码）甚至公司中某个系统怎么使用、某个流程（比如机器资源、KV资源申请）怎么走都做详细的记录。很多时候我因为提单走流程走过很多弯路，比如填写不规范被打回。因此我觉得记录这些也都是有必要的，能减少不必要的工作时间。
更主要的是人非圣贤孰能无过，我也犯过线上错误。所以我更要坚持复盘，看能否把对线上的敬畏牢记于心。也希望能从复盘的过程中发现改善和规避的方法。
复盘思维+效率意识会产生飞轮，让你处在一个正向的循环中，向着更高的效率迈进。
我的wiki在百度内部被检索到的量级很高，我们部门有很多新人看着我写的wiki来上手工作。也有其他部门的同事检索到我的wiki，向我咨询一些事情，其实我只是作为使用者，记录过相关内容，但我并不是他要找的那个相关人员。
做笔记带来的一个额外的好处是提升了你在公司内的影响力。
有意思我因为一个项目和一个架构组的同事合作，此前我不认识他。因为一些项目原因我问他：
大佬，这个XXX怎么样了。
他说：
别叫我大佬，我平时都是看你wiki学习的。
我……
后来我离职以后，还陆陆续续有百度的小伙伴，通过我的wiki找到了我的知乎，也算有趣。
（如果有百度的小伙伴看过我的wiki，可以顺手点个赞，或者留言评论一下。我的百度ID：wangwei114，没有评论的话，我过几天把这句话删掉）
2. 防病于萌
一段《扁鹊见蔡桓公》送给大家！
扁鹊见蔡桓公，立有间，扁鹊曰：“君有疾在腠理，不治将恐深。”桓侯曰：“寡人无疾。”扁鹊出，桓侯曰：“医之好治不病以为功！” 居十日，扁鹊复见，曰：“君之病在肌肤，不治将益深。”桓侯不应。扁鹊出，桓侯又不悦。 居十日，扁鹊复见，曰：“君之病在肠胃，不治将益深。”桓侯又不应。扁鹊出，桓侯又不悦。 居十日，扁鹊望桓侯而还走。桓侯故使人问之，扁鹊曰：“疾在腠理，汤熨之所及也；在肌肤，针石之所及也；在肠胃，火齐之所及也；在骨髓，司命之所属，无奈何也。今在骨髓，臣是以无请也。” 居五日，桓侯体痛，使人索扁鹊，已逃秦矣。桓侯遂死。
中学语文中的经典篇目，讲的其实就是一个要“防病于萌”的道理。中医有云：
上医治未病
更通俗一点，就是未雨绸缪。好的程序员，应该能主动预判风险，并提前规避。而不是每次等出了问题以后，再事后补救。事故补救，永远是下策。很多时候我们为什么加班，就是因为半夜里或者周末突然被告警电话叫醒，然后火急火燎的去排查问题。但其实很多问题都可以事先规避掉。
我对项目管理有几句箴言，时常敲打跟我一起干活的小伙伴们：
- 能在编译阶段发现的，不在开发自测阶段发现
- 能在开发自测阶段发现的问题，不要在正式测试阶段发现
- 能在测试阶段发现的问题，不要在预发布环境发现
- 能在预发布环境发现的问题，不在线上环境发现
当然做到这些仅凭仔细和自觉是不够的，经验再丰富的程序员都有马失前蹄的时候。另外我还有一些准则：不要依赖人的仔细，要依赖工具和代码本身。
比如我会制定严格的代码规范，避免由于笔误导致线上bug甚至事故。比如==误写成了=，或者本想用多态覆盖父类同名函数却写错了子类的函数名（可以用个override声明避免）
我会设置额外的gcc的编译参数，让许多风险代码，直接编译不通过。比如：
-Werror=return-type
-Werror=maybe-uninitialized
关于这部分的内容，也可以读一下我的这篇知乎回答中的【靠编译期检查避免粗心大意】一节：
当然，扁鹊的故事还没完，还有记载：
魏文王问扁鹊曰：「子昆弟三人其孰最善为医？」扁鹊曰：「长兄最善，中兄次之，扁鹊最为下。」魏文侯曰：「可得闻邪？」扁鹊曰：「长兄於病视神，未有形而除之，故名不出於家。中兄治病，其在毫毛，故名不出於闾。若扁鹊者，鑱血脉，投毒药，副肌肤，闲而名出闻於诸侯。
扁鹊的大哥，医术最高，但因为“未有形而除之”而“名不出於家“。这也精准刻画出了“防病于萌”这件事的一个副作用。在职场中有一怪异现象，有时候你负责的服务很稳定，线上几乎没出现过什么事故，领导会觉得你负责的模块很简单，你平时没啥事干。而如果你同事负责的模块三天两头出事故，然后各种救火。领导会觉的他服务意识好，工作积极主动，承担了很多工作。
所以我们在勤恳工作之余，也不要忘了汇报。要让领导知道，你其实干了很多事。不然会很吃亏，吃亏这件事，我是深有体会……
3. 降本增效
降本就是降低成本。这里的增效，指的是提升系统的效率、服务的效率。本回答第一节的效率意识指的是提升个人的工作效率。二者并不相同。
不知道你有没有看过《大江大河》。宋运辉毕业后在金州化工厂上班，但是作为大学毕业生的他，却没有坐办公室，而是被分配到了车间一线。后来他勤勤恳恳地工作，每天在车间，厂房检查各处的“跑冒滴漏”，给维修师傅提维修工单。大家因为他的维修单，工作量陡然增加，自然埋怨。但是最后这个车间，因为解决了这些“跑冒滴漏”，导致节约了大量成功，从而被评上了先进。
你可能会说：“传统企业的故事和我互联网码农有何相关？”
可能和初级的程序员不太相关，但是对于高级程序员来说，成本其实也是必须要考虑的。
作为互联网从业者，总是有一种错觉，那就是互联网公司最大的运营成本（或者说最大的成本）就是程序员的工资（当然也包括产品经理、运营、设计师的工资）。程序员在写代码的时候，也常常假想成的硬件资源是无限的……大不了就加机器嘛。
其实不然，机器是有成本的，而且成本不低。大的互联网公司都会评论机器的资源利用率。比如CPU峰值如果不达标的话，未来一年的机器预算就少很多。但这样的考核有时也过于简单粗暴，比如即使你的CPU峰值达标了，就能事不关己，高高挂起了么？
不然。支撑同样量级的业务，如果机器数用的越少，成本显然越低。如果你经常写垃圾代码，即使每个机器的CPU都被充分利用了，又有什么意义呢？所以关心机器的利用率，可以倒逼自己提升自己的代码水平。
互联网大厂的流量红利都已到顶，用户侧，商业侧都增长乏力。最近大家疯传的互联网大厂裁员消息也不是空穴来风。对企业来说，人就是成本。当然对于程序员来说，我们也不能把自己看作是和资本家对立的一方，优秀的程序员应该懂得更好的降本增效，公司一般不会对有能力的人吝啬。
