这是一名在硅谷工作的工程师朱赟在自己的微信公众号嘀嗒嘀嗒上新发布的一篇文章，聊到了自己对于工程师成长的一些思考。

下周公司要举办一个活动，找了硅谷一些比较 Senior 的技术女性一起做一场分享。请来的人包括 Google 的 VP of Engineering，Linden Lab 的 Director，Rackspace 的 Board Director，Medisas 的 VP of Engineering 等等。我有幸代表 Airbnb 去主持这次分享。主持的主要工作就是准备一些问题，以及在活动中引导每个 Speaker 的分享。

在做准备工作的过程中，自己不禁也对很多相关问题有了更多的思考。

我进入职场不到四年，总体说来，应该还属于一个初期的阶段。但是这四年，从周围的不同的人身上学习了很多东西，终身受益。这篇文章，着重谈两点体会。一是哪些外部因素会促进我们的成长；二是哪些方面是我们自身可以努力，以加快成长的速度。

先说成长的外部因素

有很多读者问过我，硅谷的工程师拼不拼。这个问题确实不好回答，因为方差太大。不过我身边有不少特别拼的小伙伴，每天有效工作时间都在十二到十六个小时之间。公司并没有任何加班的要求或者机制。这种勤奋是完全自发的。每个人的情况可能不完全一样，但是有两个外部因素不容忽略：一是来自团队的反馈和肯定，二是在工作中获得的成就感。

先说正面的反馈和肯定。这不一定是做了多么了不起的事情，或者是公司给了什么特别的荣誉。但在整个体系里，对个人的贡献和努力能表示出认可，这在很多时候，会不断激发团队里的正能量。一些简单的例子：可能是一封 Email 对某个人在面试上花的精力表示 Appreciation；可能是某人解决了一次线上事故后在组会中点名表示感谢；可能是老板与其 1:1 的时候直接表示嘉奖；甚至是简单的，平时组里相互调侃时大家的一句 “你太猛了” 等等。在一个相互对彼此的努力和成就表达认可和鼓励的氛围里，大家更容易开心地一起进步。

再说成就感。我觉得工程师这个群体还是更容易对自己 “做了什么” 产生自豪感，而不是自己 “得到了什么”。所以这里说的成就感就包括两个方面：一是他/她得觉得自己做的事情很重要；二是他/她觉得自己不断地有产出，完成了一些事情。

做的事情是不是重要，很多时候和团队的领导人息息相关。之前在《论一线技术领导者的基本素养》中提到过：一个好的领导人要善于 “挖坑”，也就是定义项目，安排各种工作的优先级，决定要做什么。换句话说就是长期的战略眼光。有了这样的眼光并对团队的工作有很好的计划和安排，把重要性传递给每个成员，这样，每个成员才能知道自己做的事情的战略地位，知道自己做的事情对团队乃至公司的发展是重要的。此外，适当地安排一些技术分享，让组员有机会去展示自己的工作，让他知道其实很多人对自己做的东西感兴趣，也是一个很好的手段。

而关于 “让工程师觉得自己不断地有产出，完成很多事情” 这一点，最近有一些切身的体会。我们组，总体说来每个人每天工作的激情很高，做事的效率也很高。前两天和老板聊天偶尔提到此事，他说的话我觉得很有道理：“一个团队应该有一些稍微 Aggressive 但又可行的 Milestone（里程碑），而且大里程碑分成小的，尽可能每两个里程碑之间间隔时间不要过久。这样，每隔一段时间，大家就会完成一个目标，就会有成就感。最糟糕的，就是定一些不切实际的目标，或是不断 Miss 预定的目标。这样的话，慢慢地每个人都会开始疲惫和迷惘，很难看清楚自己到底做成了什么。”

再说成长的自身因素

写公众号后，接触到很多的工程师。我朋友圈里面，和软件开发、计算机技术相关的人绝不少于一千。加上身边同事、朋友等各路大牛，我也不好大言不惭说我成长地很快云云，这里分享的仅仅是个人的看法和思考。可能也并不能对所有人、所有技术岗都适用。

我觉得技术人的成长还是要做到三个方面的平衡。哪三个方面呢？

一是思。也就是思考。你说是业务逻辑也行，说是系统架构也罢，我说的思考，是你需要不断地去想：你到底要解决一个什么样的问题？你的目标是什么？根据你的现有资源（时间、已有代码）和限制（各种业务逻辑、已有代码），你能做的最优的解决方案是什么？换句话说，我们的工作还是应该以解决问题为出发点。

一个人是不是真牛，不是看他会什么不会什么，而是看他是不是真的能把每一件交给他的事情妥妥地做成。

二是学。也就是学习。这不仅包括流行的新语言，新工具，还包括和自己工作相关的计算机理论。而这些学习的目的，就是让自己从技术出发，知道哪些事能做，哪些事不能做（比如 CAP 理论，NP 理论）；知道自己想解决的问题是不是可以抽象成一个经典的问题，或是已有类似的解决方案（比如三次握手、二段提交等）；知道别人走过的桥踩过的坑，自己是不是可以借鉴（比如关于并发、安全、性能），等等。

三是践。也就是实践。工程师的动手能力尤为重要。很多猫腻的、坑人的、虐心的问题，如果没有亲身交战过，你永远不能体会它的奥妙。而且经常动手会增强自己写程序的熟练度，提高自己的开发效率。另一个就是增强自己对问题的敏锐性。很多耗在 Debug 和 Troubleshooting 上的时间，其实从长久来看，会增加自己看问题的深度，尤其是对编程语言的熟悉度。很多时候，一个 Junior 问 Senior 一个程序相关的问题，Senior 信手就解决的，其实，没有其他，不过是因为练过经历过。

而这三方面，如果只注重任意两个甚至一个方面，你就会发现自己很努力却不见太大的进步。木桶盛水，水深总是受限于最短的一块木板的高度，就是这个道理。