程序员应该怎么忙

前几天和一个总监聊了一下程序员的成长问题，也问了他关于程序员发展的路径应该是怎么样的，今天也看了一些书。结合自己的观点，简单的来谈谈“程序员应该怎么忙”。

首先我认为程序员的成长要分成三个阶段，分别是初级程序员、技术专家和资深程序员（架构师/总监/CTO）。

第一阶段：初级程序员

第一个阶段应该算是入门阶段，这个时候由于刚刚脱离学校，对于整个社会、专业、公司等可能了解的都不是特别的清晰。所以这个阶段适合是做一些探索性的事情。在第一阶段里面，我认为投入一定的时间是必要的，因为我们不确定我们自己的长板、优势和兴趣在哪里，需要不断要去探索试错和寻找到正确的方向。

比如对于我来说，我可能不太明白自己适合哪种业务，是走技术深一些的中间件业务，还是走上层对客业务。基于上面对于自己的兴趣点和性格发掘，在实习的时候，我就选择了去腾讯的业务部门，一来对于腾讯这样的平台来说，他做的大部分业务都是面向于C端客户，也就是影响的用户其实是非常多的。第二个是我做的是业务部门，所以做出来的产品马上就会有客户来使用，并且我就能够收到反馈，所以这两个特点都是比较符合我的兴趣的。以我这种急性子，根本等不到静坐着研究个一年半载，才收到用户的反馈，我非疯了不可。

我刚到阿里巴巴就被分到了2B的交易系统，我确实不知道自己喜不喜欢做企业级服务类的事情，做的是商家的交易平台，这个也算是比较核心的功能之一，毕竟电商最核心的就是做交易系统。但是我明白自己一点，就是一定想做有一些影响力的事情，并且想做一些快速投入，能够快速产出的事情，或者说，我喜欢做有快速反馈的事情。

因此我在这两个公司算是度过了我第一阶段的成长的阶段，在这里面我观察了很多线上的业务、客户、技术方案、技术架构等等，也初步学会了怎么样去判断一个业务的发展路线，怎么样去判断业务的可行性。当然更重要的是也了解到了怎么样用技术来解决业务问题。

第二阶段：技术专家

相对来说第一阶段实际上时间非常的充分，因为刚刚毕业，孤家寡人可以把大量的时间投入在公司的业务编码和学习上。除了周末偶尔和朋友出去玩玩之外，大部分时间都花在了和工作相关的事情上，加班加点可以说是一个非常常见的事情。虽然现在回过头来看，很多时候做的业务上线后往往是没什么结果的，但是那个时候第一个我自己不知道，第二个我自己也没得选择，我只能在不断的迭代中去写代码，去提升自己，去了解和熟悉业务。虽然如此，还是乐此不疲，也不明白生活的意义是为了什么，只知道自己一无所有，想立足下来，只能先当孙子，享受自己加班忙碌的时间。

到了第二个阶段，我发现在时间和精力上已经有点跟不上了。一方面也是因为自己的年纪大了，到了差不多30多岁的时候，我加班跟不上别人，而且连我长时间想坐在凳子上都有点坚持不住了。另外一方面，有了家庭之后，我会发现我很多的精力就会被分散了，完全不能像以前那样，吊儿郎当。

到了第二个阶段以后，我发现一个事实，那就是中间人已经逐渐的发现自己再不能去跟之前一样去熬时间，去熬精力了。

我一直在思考，中年人更有竞争力的到底是什么，现在思考下来我觉得更重要的是专注和洞察力。专注指的是自己在业务方向和技术方向上应该都有一些非常确定的沉淀，知道自己要做的核心事情到底是什么，自己的核心技术和业务优势是什么。30岁左右的时候，已经不可能耗费大量的时间去尝试做各种各样的事情，甚至在下班以后还能再搞一些额外的学习或者什么的，到现在这个阶段这个已经非常艰难了，此时而应该专注于在自己非常擅长的地方，或者是整个目标特别确定的地方。

洞察力则是体现对于某个业务和技术的判断力上面。在你年轻的时候，你可以跟着产品或者技术上的同事一起做很多探索性的事情，不断的去试错纠错，往返迭代等等。到了第二个这个阶段，你就没有时间和精力去做这样的一些无效的试错，你必须要有非常准确的判断力来判断一个业务是否可行，来判断一个业务的设计是否合理。甚至我有时候看产品提出来的方案，我只要看一眼，我就可以根据过往的经验判断这个功能是不是可行。当你积累了5年-10年的客户经验的时候，你大概率可以一眼判读客户要的是什么，不要的是什么，哪些客户愿意付钱，哪些只是花架子。

在自己第二个阶段的时候，已经没必要做很多件事情，你只要做一件事情，一件你认为最重要的事情，并且不断的纠偏和推进，直至最后拿到业务结果即可。

但是到了第二阶段也是非常难的。一般来说有两条路线，第一种是技术专家，标准是业务专家。不管是业务专家还是技术专家，这是两条路线都要求专注，只做最重要的一件事情，而不是漫天开花。

比如我在现在负责的是钉钉工作台，钉钉工作台有两个定位，对于普通的中小客户来说是应用的入口，对于大企业来说，工作台是企业的门户。工作台做到如今的这个程度已经比较稳定了。但是要解决的扩展功能特别多。一方面我们有很多产品规模目标或运营既定的商业化营利目标。当然除此之外，由于我们的产品在线上跑了很久，人力不足，也导致我们线上的产品的Bug非常的多，我们基本上每周都会接到大客户的投诉，投诉我们的部分功能不好用，或者不符合预期。在这种情况下，我们又必须要安排人力去修复这些线上问题。除此之外，除了系统上的问题，我们还有交互上的优化，性能上的优化，还有老板加塞的紧急需求等等。

在这么多并行的事件，而且看起来都非常的重要，同时摆在我的眼前的时候，看起来都需要做，但是我们只有5位研发同学，我又要对整个团队的最后结果负责，也就是在半年或者一年后，我这个团队如果只有一件事情拿出手，我应该拿什么？

所以对于我来说，我认为我最重要的一件事，就是思考工作台团队这一年的核心目标是什么，我最重要的事情是什么，我拿到了什么样的结果，而其他的事情是不是非常次要，优先级都可以往后靠，《专注一件事》里就明确提到，“平衡是一件不可能的事，选择了平衡，你就选择了庸俗，以为你没有把精力投入最专注的事情，就不可能有个优秀的结果”。

如何找到团队最重要的事情，我继续解释一下，所以基于我们上面说要说的各种各样的目标，我认为综合而言就是我要在团队集合所有兵力，降低整个PaaS工作台的门槛，这个才是作为一名技术能发挥出最大的主观能动性同时能够拿到业务收益的地方。

不管是商业化项目还是增加用户的规模，它的底层都依赖于我对于PaaS能力的构建，也就是我要充分降低PaaS的产品门槛，这样客户才能用得起来，大客户也愿意为其买单。

所以在定下了核心的方向之后，我就要进一步去拆分，要完成这一件事情，有哪些核心的点我要去解决。

其实对于主管来说还有个非常大的挑战，就是当你明白你最重要的事情是什么时候，你最终要做最艰难决策的并不是一定要去做什么，而是你不去做什么，因为这样你才能够集中所有的精力去解决你最要专注，最应该完成的一件事情。

当然因为是一个团队，本身就应该要保障你整个产品的完整性，比如次要的线上的问题也必须要去解决。所以在此过程中我也会安排适当的人力来支持一些必要的需求，比如说修复线上的Bug，比如说设计商业化的基础链路等等，但这些都是一些辅助级的目标，并不应该占用你的大部分精力和注意力。通常来说一个人的意志力是有限的如果你的团队的主心骨放在了某一件次要的事情上面，整个团队就不大可能有心思去思考团队的最重要的那件事。

当然我们所说的要做一件事情应该就不是一件特别小的事情。比如说作者只是把自己定义成写一篇文章、前端工程师只定义出写一个页面，这些根本也解决不了什么大的问题，也产生不了什么大的影响。所以如果把这件事件定义的太小，他解决不了任何问题的时候，这件事情做的再好也没有什么用。这件事情的定义必须是我们要解决一个什么样的问题，并且这个问题是用户特别关注的问题，同时还要具备一个特性，就是你解决的这个问题，别人是很难解决，甚至是解决不了的，这样才能体现你的差异性和价值，否则比如要去开一个小店，没有任何优势，可能根本比不过一个热情好客人缘好的大爷去开个小店。

确定了这件大的事情以后一个要一个人要完成这一件大事，只有两个方式。第一个方式就是把时间拉长，一个人慢慢做一年，两年甚至十年，完成一个很大的工程。很多个人创作型的方式都是这样的，比如说写作，比如说科学论文等等。对于技术人员来说，目前一个人耗费个几年来写出一个软件，可能需求早就变化了。因此对于程序员来说到了第二个阶段，就必须要依靠团队的力量来实现第二个阶段的协同结果。

第三阶段：资深程序员

第三阶段当然是做一个Scope更大的事情。当然第三个阶段我也远远没有到达，所以也没有办法跟大家分享自己的经验。希望后续有机会和大家聊聊，作为一名骨灰级程序员或者是资深业务架构师的时候，再来和大家谈谈，如何成长。