这几天，“10x工程师”这个词又被炒起来了。源自一位投资人在推上的“不靠谱”定义，让大家大为吐槽。
 
借此，我也在这里，说说自己对10x工程师的理解，以及一些可落地的进阶方式（而不是画大饼的提出一些假大空的概念）。
 
尽量对比着这位投资人描述的内容来做一些修正。

10x工程师不一定讨厌开会，而是看会议本身的价值和效率。召开会议，要有明确的话题，明确的结果标准，明确的参会人员。在快速，高效的讨论后，得出可以快速推进工作的结果，才是会议的意义。如非此类，才令人讨厌。

对于深夜写代码这件事，至少我个人的看法是：这已经不是上世纪九十年代了。虽然很多人都在年轻的时候熬夜，觉得安静的夜晚写代码更有效率，但是事实上，在积累了一定的工作经验和亚健康之后，早睡早起以及适当的运动才是提高工作效率的根本。

终端在很多情况下是高效的工作环境，但也不是全部。

他们不一定知道生产环境中的每一行代码，哪怕代码全部是他自己写的。只是，他们会定义一些编写规范，然后即使不是自己写的代码，也可以快速的定位问题。

虽然我个人不太喜欢全栈这个词，但是不自我建立技术领域壁垒是真的。

第六条不反驳
我觉得，没有人能把所有的文档都记在脑子里。但是，优秀的文档和接口设计，可以让使用者简单且快速的猜到自己想要的接口。以及，有效的代码提示工具也可以在大多数时候提供帮助。

第八条不反驳
重申，这不是上世纪80年代了。我记得，有一本书的名字叫做《不会带人，你就自己干到死》，你可懂？
这句话很像《程序员修炼之道》里面的一段描述，曾经我也深以为然。但是，我现在觉得，“不要以为Team里面的每一个人都和你有一样的认知”，不要想当然的以为你的代码已经可以优秀到别人不看文档都可以看懂。至少我工作的十几年里，还没有遇到这样的工程师。
呵呵呵……
 
额外，我再加一些自己的补充，用于描述10x的程序员，是如何10x的：

定义规范（如果有社区里面已经定义好且成熟的，建议参考），甚至使用一些自动化的检查器来约束自己和Team，会帮你节省很多差错和思考的时间。
自动化测试代码，如果你的项目是持续维护的，每次写完代码，你只需要“make test”即可知道你新加进去的一大坨东西是不是可用。
经验的积累，主要是让你以后少犯同样的错误，所以，总结记录是很重要的。
写代码前先思考，思考Feature的逻辑是否完整，会不会出现代码写了一半多，结果逻辑要重新整理的情况。你想要写的代码逻辑，是不是通顺，是否与现有的技术架构不符。思考清楚了之后再写，会减少很多返工。
把所有的有效积累传播给其他的工程师

那么，你的Team就会因为你，而大幅度提升工作效率。从而，在单位时间内，多交付出1人，10人，乃至百人的工作量。那么，你就成为了那个名副其实的10x工程师~
 
 
 

作者：隋龙飞