通过劳动使自己充实，抚慰精神创伤，使自己强大，愈合自己的精神创伤，升华自己的思想。 — 路遥

最近公司的需求是源源不断，几乎都是问题着问题，项目叠着项目。在这种高强度的工作中，几乎没有一点点自己的思考时间，很容易精神消沉，而精神上的消沉无异于自杀。因此我在想，如果每天都是这样，可不就是通过繁重的劳动来使自己充实么，然而不是的，这种高强度的工作使我越来越迷失，感觉到一种空虚。

下面是在我下班后闲暇之余，考虑了一些个人和领导层面的思考，希望对大家有所帮助。

计算机基础和代码能力最重要

这一条得到所有人的认可。只有具备了扎实的计算机基础知识（操作系统，算法，数据结构，分布式等等），才能在学习新技术的时候快速地理解和上手，否则就会遇到重重困难。算法和数据结构是代码能力的基础，如果这个不过关，无论是读别人的代码，还是自己写代码，都会很吃力。如果感觉自己在基础方面有薄弱环节，建议业余时间自己补上。例如，如果感觉自己算法和数据结构不过硬，可以多刷一些算法题提高自己；如果感觉自己在分布式方面不熟悉，可以多看看分布式方面的技术书或者文章。

沟通能力非常重要

软件工程师不是自己一个人闷头做事，需要跟其他同事协作，有效沟通才能保证协作顺畅，产生最大收益
如何沟通：
1） 积极主动，遇到问题主动找人讨论，很多好的想法都是在讨论过程产生的
2） 有准备的沟通效率更高，在与人讨论之前，先自己思考，有了一些想法之后再找人讨论，做到有的放矢

工作过程的总结和记录很重要

把工作过程遇到的问题和解决办法随手记录下来，养成习惯。一方面，可以在一段时间之后能找出来使用，避免遗忘；另一方面，在别人遇到同样问题的时候，可以作为经验参考，避免重复做同样的事情，造成时间和精力的浪费。
每隔一段时间，或者每做完一个项目，根据自己记录的经验做总结和在团队做分享，既可以总结自己的经验和不足，提升自己对技术的理解，又可以用自己的经验帮助到别人。
在跳槽找工作的时候，这一点也非常有用。面试官经常会问类似问题：你在过去一年遇到的最大的技术难题是什么？如何解决的？你的收获是什么？如果平常不做记录和总结，面对这样的问题估计会不知所措。

提高自身的软件工程素养：重视测试和 design/code review

测试（单元，集成，回归）既可以保证功能的正确，又可以从用户角度审视自己的设计，还可以保证后续修改代码的时候避免引入新的 bug。
design review 可以保证设计方案的正确性，在编码之前提前发现问题，还可以一起讨论方案的优化思路，确保方案的相对最优性。
code review 可以帮助审查代码逻辑是否有问题，模块和层次划分是否合理，是否有好的健壮性和可扩展性。

知其然更要知其所以然

对于项目中用到的技术或者开源组件，不仅能正确使用，更要了解其内部实现机制。
例如程序开发中用到 sql，不仅要学会写 sql，优化 sql，还要了解 sql 是怎么被解析，优化和执行的。
例如程序中用到缓存组件（比如 LRU），不仅会用，还要了解底层的实现原理，包括算法和数据结构等。

关于增量价值

完成项目目标是最基本的要求，公司最需要的是能够实现增量价值的员工，就是说，不仅完成项目功能，还能够给自己提出更高的目标：这个方案是最好的吗？还有没有更好的方案？性能还能不能再提升？能否做一个通用的工具？是不是可以贡献到开源社区？有没有可以创新的点，能否写个专利？归根结底就是：要做一个对技术有追求的工程师。

技术的广度和深度哪个更重要？

显然，技术的广度和深度都很重要，二者是互相促进的关系。作为一个资深工程师，肯定要在某一个或几个方向做到深入和精通，另外，对于其他技术方向也需要广泛涉猎。技术都是相通的，同一个技术在不同软件里面实现不同，但是原理基本是一样的，多了解一些方向可以从不同角度去理解一个技术，做到真正的深度理解。例如线程模型，在 c++，java，和 go 里面的实现都不太一样，在学习了他们各自的实现之后会更加深入地理解进程，线程，协程这些基本原理；再例如分布式一致性，有 zk，paxos，raft 等等，熟悉了他们各自的实现机制，能更好地理解各自的优缺点，因而在项目开发中需要做分布式一致性选型的时候就知道怎么选择。

基础架构人员是否需要理解上层业务？

这个问题的答案应该是一个度的问题，基础架构人员在基本了解上层业务需求之后，就可以提供服务，但是如果能更多了解他们的业务，就可以从另一个角度来思考基础服务，从而提供更精准，更有效的服务。当然另一方面，基础服务需要的是通用性和健壮性，在实现层面要尽量避免业务特殊性。