以下文章来源于技艺丛谈 ，作者叶顺平

点击上方蓝色“Go语言中文网”关注我们，设个星标，每天学习 Go 语言

公司之前在总监层面推行企业文化建设，CEO作为表率，先写了一篇很好的HTWWM（How to work with me），然后要求各个总监也写一篇，我也写了一篇，虽然不是很系统，不过基本上描述清楚了我喜欢和什么样的工程师共事，也说清楚了我自己在追求成为什么样的工程师。公众号的读者基本都是工程师，放在这里，供大家参考下。后续有时间，我也会总结下我阅读我所在公司各个总监的How to work with me得出的一些职场经验总结，希望能对大家有一些帮助。仔细阅读一遍，对我自己也蛮有帮助的，尤其是不同岗位和级别的同事文章里提到的一些非常不错的职场素质，对作为工程师的我挺有借鉴意义的。

下面是我自己的 How to work with me，不过说明下，我自己欣赏这些品质，并不意味着我自己能够完全做到，还得再接再厉。

三思而后讨论

我欢迎大家找我讨论问题，但是希望在讨论之前，可以先想想自己的解决方案，使用下Google搜索引擎。如果可以，最好也先和身边的同学沟通下。为了使讨论更加高效，我希望先听到你对问题的分析。

给结论，也给原因和过程

我希望看到一个结论的时候，也能够有对应的分析数据。比如，一个模型变好了，我希望看到变好了多少，是否也有一些变差了？最好也能给我说明下，变好了是使用了什么新方法，做了什么改进？如果是产品经理给工程师提需求，请说明白你的需求，也说明白需求背后的动机。

Code review 前的基本功

我很喜欢做code review，但是不希望做不必要的机器能做的工作。在做code review之前，请先跑一下自动化脚本，分析下代码风格。也请自己先review至少一遍，先过了自己这关，再让同事帮忙review。另外，review request 请不要每次几十个文件，能做到细粒度就尽可能拆分。

永远不要说不可能

不要说竞争对手也是这样，甚至更糟糕。我们要做的是领先的事情，所以不要老和别人对比。另外，说别人也不行时，希望看到量化的对比数据，我们的怎么样，对手的怎么样？

工作进展从周报进展开始体现

一些同学写周报的时候，经常是 high level 的描述，比如改进XX分类效果，比如fix crash , fix jira issue, 或者跟进XX项目进展。甚至好几周都使用类似的描述。我不喜欢这样的周报，我喜欢每周都有不同的描述。事情可以是同一间，但是进度应该进行分解。OKR也应该进行分解，有阶段性的产出。

提高主动性，保持双向沟通

有一些人主动性不够强，总是需要Leader去催进度，或者是关注工作进展。优秀的人应该主动出击，有项目上的进展，有工作上的问题，应该随时保持沟通。这样彼此的时间才不会浪费在猜测和沟通上。

敲代码前先讨论

对于不清楚怎么做的事情，或者复杂度较高，超出自己把控范围的，建议先找其他人做好沟通，而不是憋了半个月一个月，快上线了，我们才发现方案完全不可靠，或者是代码库里已经有类似的工作了，或者性能完全不符合预期，或者实现的目标不太贴合使用场景。

写文档的好习惯

有一些改动如果比较复杂，或者比较 tricky，我希望能够添加足够的注释，充分的测试用例，甚至写一份简单的Google Doc，介绍下原理和工作流程， share给团队的人。

主动站出来

项目中遇到难题，我欣赏那些主动站出来，想办法解决的同事。总是躲在后面的人，不是你庆幸工作更轻松了，而是 Leader 在以后根本没时间关注到你了。

要事优先

如果你手头有很多工作，不知道优先级，请找你的Leader沟通清楚。大家的时间都有限，要事优先可以让我们的效率最大化。

能不断发现问题和不足

我欣赏那些在开组会，或者是讨论问题的时候，能够不断提出问题、发现问题的人。我不喜欢不懂装懂的人，我欣赏不懂却敢于问出来的人。搞明白别人方案的优雅之处，或者思考是否有改进空间，都是很好的习惯。

帮助团队成长

任何人为自己长期的职场成长做规划都是对的，但是我不喜欢老挑活的工程师。真正优秀的工程师，在解决各种疑难杂症中成长。我欣赏那些自己努力，也努力帮助身边的工程师成长的人。只有整个团队成长了，才能一起做更有挑战性的事情，共事本身也才会更愉快。

有干货乐于分享

如果你工作上有很多新的收获，或者是读代码时看到很多不足，希望能及时分享出来你的收获，及时公开你发现的问题，让大家从你的经验中、从你发现的问题中一起成长。
]