1. 尽量努力的多去阅读别人的代码，越多越好
阅读代码，需要看开源的好代码，跟着文档品读那些开源的优秀代码的卓越之处；
但也要耐心阅读自己公司的各种代码，对于公司的各项目代码和问题要有十分深入的了解，
使得自己的技术方案在落地的时候避免出现脱节和及时给出最合理解决方案。
除了技术能力，还需要培养作为技术专家解决公司实际问题的能力。
对公司这些代码读的越通透，掌握的越多，越能快速把控代码，让以后对这些代码的变革变得更容易。
而轻松修改、革新这些代码的能力，就会变成你在这家公司不可替代性的重要因素。
所以，各种代码，无论质量好坏，都需要能读懂读通，并且读的越多越好。
能读懂读通任何质量的代码，才是真正的掌握了阅读代码的能力。读的越多，则能识别代码质量的能力就越强，将来自己就越能写出更好质量的代码。
2. 能准确判断项目的发展方向
增加对项目发展状态的精准判断。
根据用户反馈和市场行情，调研了市面上竞对产品的基础上，项目不应该部署复杂，对应的一些辅助工具链也需要及时开发出来。
3. 去主动管理会议
- 会议提前和参会各方沟通，开会时间尽量协调到一起，把当日所有可能的会议都集中开完。之后就会有连续的时间去深度工作了。
- 在开会前一天，把会议内容和可能出现的问题都预先做功课。一方面是防止会议开着开着跑题；
二是万一出现争议问题，可以列举出来事先准备的技术方案，这样也能加快会议进度。 - 对于一些不那么重要的会议，需要态度坚决的避开或者指派别人参加。
4. 版本控制工具的熟练应用
对于版本工具使用不当，会耽误开发人员很多时间，会造成许多问题。比如，各种各样的代码冲突、版本重叠，莫名其妙的代码丢失。
每次负责一个新项目，严格指定版本工具的使用规范，对开发人员统一培训版本工具的使用。
同时，也会把各种技巧、注意事项、常用命令整理好，放在内部的共享文档中。
5. 不要把解决方案复杂化
关于技术和技术落地之间存在的问题。
程序员的炫技某些时候会导致整个系统复杂化，最终产出反而不尽如人意。
一个公司内部使用的小项目，没必要为了各种概率很低的风险，把明明很小的一个功能给做的很复杂。
针对这种问题，就需要技术 Leader 及早发现、介入，防止出现过度设计、过度开发。
6. 把任务安排的井井有条
对于任务紧急程度的判断都是经过深思熟虑、实际分析过的，任务之间的先后顺序，也和任务交付人认真沟通过。
有些任务之间是关联的，完全可以融合一起搞定，不应该割裂开安排。
对一些根本没必要的任务，需要态度坚决的对这些任务说 No。
7. 不要死板的写代码
很多程序员知识面很宽，基本功也非常扎实。但是，有一种能力，是学校教不出来、面试也不容易看出来的，就是代码能力。
所谓的代码能力，有的是指写代码不出 Bug 的能力，有的是指算法落地能力，还有不写死板的呆代码的能力。
我们都知道，程序员少不了要维护老项目。在维护项目的时候，我们面对各种不断的新需求，经常要去修改代码。
修改代码是个很危险的事情，因为我们修改的代码往往会和别的功能耦合住。
改了一点代码，结果影响一大片功能的情况经常出现。最虐心的是，这种连带影响可能不会马上出现，不知道哪天就突然冒出来折腾一把。
所以，对于修改代码的事情，我们需要学会的是不要写呆代码。你不能写完代码运行下没问题就觉得正常了，你在写代码之前需要好好思考。
这种思考，既不是什么搞设计模式松耦合，也不是搞功能切分独立成块。这种思考本质是需要你写代码前去理解业务，去真正明白业务在实际是怎么运作的。
简单说两个例子：
7.1. 修改完代码后，用户会怎么使用你现在修改的功能？
比如，你修改了注册功能，可以兼容第三方登录。那么，可能有的老用户会重新注册一个账号，以方便第三方登录。那你对这种情况，其实该做的是绑定，而不是让用户重新注册个新账号。
这种疏漏，等到上线之后才发现就晚了。这不能完全依赖产品经理，作为一个技术人员本来就应该对自己的功能做通盘的考虑，这才是真正的负责。
7.2. 你现在修改的功能，会不会由于运营需要，会换成你完全没想过的用法？
比如，你搞一个用户充值功能。本来你只是想着用户游戏内购直接充值即可。但是，在实际上线后，有时候运营为了方便 vip 客户或者为了和第三方渠道互换资源，也会使用这个充值功能。
运营大批量的连续充值，并且这些充值转换成系统中的货币，就像游戏中的元宝，就有可能超出 C++ 中的整数上限，从而造成问题。如果你提前知道用户、运营人员都是怎么使用这个功能的，你就会把数据类型修改成 Long 了。
参考：技术总监的忠告