但成为开创者的路是很难很难的：
第一条路就是，你在某个领域拥有绝对专精的能力，并且正好遇到了风口。这条路上的标准模板，就是学术界往工业界转型的大牛们。这一点上，我在大学就确定自己并没有足够的耐心和兴趣做可能看起来没有什么短期收益的学术，我更喜欢解决实际的工程问题，所以已经放弃了。
第二条路是，你是一个文艺复兴式的「全才」，这里的全才不仅包括了技术能力，还有管理、交流、视野、逻辑思辨甚至审美、写作能力等等。这条路上的标准模板，就是优秀的独立开发者，还有大部分技术出身的公司创始人。在技术水平上，他们可能并不是最优秀的那群人，但他们懂得如何面对真正的用户、如何经营自己的项目，这些看起来很务虚的内容，并不会比技术问题简单多少。
刚毕业的时候我是一个技术唯上的人，觉得我只要有 Book Smart 就够了，学好数理化，走遍天下都不怕，这家干得不爽了，我可以立马去下一家，毕竟哪家公司不喜欢一个优质的螺丝钉呢？
但随着工作经验的累积，看到、接触到的范围更广，我发现如果未来需要突破一些天花板，不想当一颗螺丝钉的话，光有 Book Smart 是完全不够的（毕竟走的不是硬核科研路线），Street Smart 在一些时候也是相当重要的：你要学会如何推动手上的事情，如何向上向下管理，如何与别人达成利益一致，如何简单清晰地表达自己的想法，如何更有性价比地投入时间和精力…… 这些也是一个工程师的软实力所在，随着工龄越来越长，这些看起来不那么硬的因素，或许就会成为区分点所在。
（PS：不过我也要泼一盆冷水，以当下很多同行的技术水平之差，还轮不到拼这些软实力。）
大公司的生存之道
在腾讯呆了三年，就这样慢慢变成了一根「老油条」，也学到了不少在大公司生存的经验，下面几点是比较有深入体会的，所以想分享一下。
1. 提升你的影响力
几乎每家大公司，无论 OKR 还是 KPI 还是什么别的考评制度，一定都会有一项很重要的因素叫做「影响力」。所以每年考核季的时候（比如腾讯的一月和七月），你就能看到各种奇怪的开源项目、一连发好几篇的技术文章、内部分享课程、公众号推文如同雨后春笋一样冒出来，这些背后的推动力，就是对影响力的考核。（但我始终相信，长期来看影响力这一点并不是能够临时抱佛脚出来的。骗得过一两次考核，骗得了三年五年吗？）
所以如何建立影响力呢？
最简单的方法，就是去吃下一个项目，成为项目的核心维护者，大家遇到这个项目的需求或者问题，都会第一个想到你，把你默认作为 owner。当然这个前提是你有能力吃下项目，并且维护。众所周知几乎国内外所有的公司，很多项目的代码都接近「屎山」，我现在越来越觉得能够短时间内搞清楚一堆屎山，并且渐进式地改良它，也是非常重要的能力。
第二个方法，去为团队提供好的、正确的东西或者决策意见，这点在国内尤其重要。目前国内因为行业发展速度太快，基础知识过硬的程序员实际上是少数的，即使是大公司，也有很多人也并不是科班出身，做一些设计的时候更多是基于多年的经验，而不是基于系统化的理论知识（据我观察年纪越大，这点越明显）。
未来可预见的十年内，这个状况会一直保持。这就是能让年轻人打出优势的地方，也是我为什么除了感兴趣之外，平时都会读大量的专业书，哪怕跟我的工作领域并不那么相关。我们要做的是出卖自己的知识、能力、学识给公司，而不是卖自己的人肉劳动力。
2. 与其埋头加班，不如想想怎么提升效率
在国内工作，不可避免的一个问题就是加班，但其实大公司里，加班也分成好多种：
工作量太大or项目赶时间而加班；
白天时间都花在开会、讨论、对接各种人上了，没时间干活，只能晚上干；
反正回家也没事干，不如呆在公司吃吃喝喝吹空调上上网；
要绩效考核了，表演式加班。
后两种纯粹是自作孽，我们就不做评论了。主要想讨论下前两种加班：
前段时间因为团队业务的扩张，我也遇到了第 1 种的问题，当时的想法其实是很「头铁」的：突然来了这么多工作量，那就正面刚嘛。直接结果就是，我一个人干了好几个人的活，连续几周都处于工作压力很大的状态，对身心健康都造成了负面影响。后来才知道，整个团队的工作量其实并没有那么大，只是存在分配不平衡而已，如果我能把手上的一些任务拆分出去给到其他人，其实大可不必这么辛苦的。
在刚毕业的时候，我完全不需要去考虑怎么分配任务的问题，因为那时候我更多的是一个执行者，把交给我的任务优质地完成就好了。但现在，我也要开始学会如何去承担一个 owner 的职责：把任务合理地拆解，分配给合适的人，并且关注整体进度和交付时间。
第 2 种，需要反推团队去提高交流效率，比如规定每次的讨论结果必须落地成文本、每次讨论前需要准备基础的材料发给大家看等等。这点上，可以先从自己做起。我曾经也有一段时间，一旦遇到什么问题，就立马去找人聊，后来发现这样其实是很低效的。最高效的方法还是先自己思考清楚要聊什么，自己有哪些想法和备选方案，再找相关的人讨论，这样也节省了双方的时间和精力。
3. 主动承担
「主动承担」这个词听起来很官方，很像宣传标语，也是腾讯每半年考核的一个维度，但我一时也没想到什么更加口语化的说法。
什么叫主动承担呢？日常工作里，总是可以遇到很多边界模糊的东西，比如：
你提交了代码，发现跑了几次测试用例，都是时好时坏，而团队里也没什么人愿意花时间去修复不稳定的用例，多跑几次能过就行；
团队维护的核心服务还是跑在老爷车基础设施上，虽然公司在鼓励上云，虽然老爷车效率很低，但因为还能跑，所以就没有动力去迁移；
团队的项目代码缺乏基本的 lint 工具、git hook、git commit message 格式校验，有的甚至连基本的 CI 都没有；
经常收到各种用户的工单，问的都是同一个问题，也没有人考虑写一篇文档彻底解决疑问。
这些都属于「房间里的大象」，也就是非常显而易见，可是却一直被忽略的东西。它们可能是一些脏活、累活、难活，但对于整个团队的效率、交付质量非常重要，需要有足够的人力投入。
这些边界模糊的东西就是需要去主动承担的点，是除了完成团队本身托付的任务之外，还能创造额外价值的点。
作为一个从小到大性格上都比较强势的人，我经常出于“我靠我实在看不下去了”的心理，去做一些份外的事情，这些份外的事情给我带来额外负担的同时，也让我有机会去引导团队的发展。当然我也希望我的同事都是能够主动承担的人，这样我也不会这样心累了（逃）。
4. 学会引导团队的发展
《乔布斯传》里提到过一句话：“消费者并不知道自己需要什么，直到我们拿出自己的产品，他们就发现，这是我要的东西。”
其实工作上也是如此，即使单纯从技术的层面讲，不少人也并不知道什么是好的、正确的。比如曾经的我，认为以下真理是不言而喻的：
写自动化测试用例不是浪费时间，而是提高效率；
面向对象或者函数式的代码，比面条代码好；
有类型检查，比没有好；
把服务容器化，比跑在虚拟机上好；
严谨的对外 API 设计，比随心所欲的好；
精简到两三句话就能把事情说清楚的文档，比一大坨不知所云的文字好。
……