技术工程师的自我修养

自己做的东西交付之前先测试一遍。

解读: 要做一个靠谱的工程师, 对自己交付的结果要负责, 建立起个人的声誉.

问别人之前最好先自己google一下，以免问出太低级的问题。

解读: 你遇到的问题，大多数人都遇到过，并且网上都有完整的解决方案，你不是找不到，你只是你得去找。

不要炫技，面向人脑编程更便于维护。

解读: 不要利用语言的很少见的特性写一些奇奇怪怪的语句, 代码可读性和可维护性更重要.

考虑可维护性比考虑性能更重要。

解读: 在项目早期,不用太考虑性能问题而产生过度设计.

把觉得不靠谱的需求放到最后做，很可能到时候需求就变了，或者取消了。

解读: 觉得不合理的可需求以据理力争, 不靠谱的放到最后来做,没准后面大家的想法都变了

熬夜低效率写代码，不如好好睡觉。

解读: 效率第一,只看产出, 拒绝低效加班

学会如何定义问题

解读:很多需求是解决方案，告诉你应该怎么做，但却不告诉你这个问题是什么，不要将解决方案和问题本身混淆了。
问题是客观存在的，但解决这个问题的方案不只有一种，应该积极参与讨论，找到研发业务产品三方都能接受的方案。

把事情“搞定”，以结果为导向

解读:如何定义搞定，代码写完，测试跑好，新功能上线，用户能够使用我们的功能，产生业务价值－这才算是搞定
又快又好的完成产品交付

注重细节，工作追求卓越，精益求精

解读:
代码不仅能跑，而且要漂亮整洁，见代码如见其人
文档不仅能用，而且格式排版漂亮，逻辑结构清晰，经典文档永流传
现有流程够不够自动化，有没有更好的改进的方法提高工作效率

责任感，团队荣誉

解读:
项目的成功，是团队的成功，失败也是团队的失败。
线上bug原则上个人不问责，团队整理工作机制和方法反省改进和提高

持续学习，乐于分享

解读:
保持学习的热情和对新技术的探索，好的技术，工具，工作方法和理念要引入到团队中

技术工程师的几个层次：

1　需要在他人指导下才能完成某个功能的开发
2　能够理解产品需求，独立完成一个功能模块的开发, 具备独立解决问题的能力
3　能够带领一个团队，完成一个系统的设计开发和架构能力
4　能够主导公司的技术发展方向和技术演进战略