生活是关于边际收益的考量

  • 问题的关键是性价比

35岁似乎是互联网工程师们的一个坎。我们经常自嘲35岁就要被优化了,但被优化和脱发一样,能自嘲的人多数还有回旋的余地,我们只是用自嘲来表达不安。就像不知道秃头的临界点在哪里,谁也不知道被优化什么时候发生。这种困境尚未来临,但它像后退的发际线一样,若隐若现。我们只有相互调侃,确认大家都在泰坦尼克号上,才能稍稍感到安心。

技能随时间贬值的现象随处可见。光鲜亮丽如娱乐行业,也有30+的女明星在台上抱怨因为年龄增加,只能开始演婆婆、妈妈这些配角。在吃青春饭的娱乐行业,年龄困境并不奇怪,为什么在知识技能为主的互联网行业,年龄困境也如此突出?而且相比其他知识行业,年龄困境在互联网行业似乎来得更早。

最直接的原因是互联网行业知识的快速更新导致技能迅速贬值。互联网技术迭代之快用日新月异形容毫不夸张。现在的技术随着时间急速贬值,五年前流行的软件现在也许已经无人问津。知识半衰期这个概念恰好可以描述这种现象。知识半衰期是说在某个领域有专业知识的人,如果不再学习,在一定时间之后,基础知识仍然可用,但是一半的新知识已经落伍。

互联网软件行业也许是知识半衰期最短的行业之一。如果医学的知识半衰期是十五年,硬件行业的是十年,那么软件行业也许只有五年。而且学习新技术需要持续的投入,即使资深工程师也无法幸免。

从25岁入行到35岁,经过十年奋斗,大部分工程师已经成为公司骨干,工资水平逐年上升,但对学习新东西的投入却在逐年下降。家庭生活需要的精力越来越多,进一步压缩了更新技能的时间。结果是过去的知识逐渐陈旧,新的知识却没有积累起来。而随着资历增长,我们越来越抗拒加班,也越来越挑剔工作内容。在企业眼里,这样的员工性价比不如资历浅的新人并不意外。

  • 技术的更新是渐进式的

问题是,随着年龄增加,人的记忆力等也许会逐渐下降,但总体的学习能力是可以长期保持的。理论上,只要持续投入,知识技能可以不断更新。为什么很多人明知道现有的知识会贬值,却不愿投入学习新技能?另一方面,如果被优化的压力如此巨大,为什么不足以激励人们继续投入?这个逐渐落后的过程是如何发生的?身处其中时我们又是如何看待这个过程的?

《杀死那个石家庄人》里有一句歌词,如此生活三十年,大厦忽然崩塌。其实大厦从来不是忽然崩塌的,知识也不是一天之内陈旧的。对软件行业来说,虽然每天都会有新知识出现,但具体到一家公司一个岗位,技术更新都是渐进式的。RestAPI也许会被gRPC取代,可是绝不会再一天之内发生。

即使需要学习新技能,偶尔花费精力学到够用的程度也把不困难。学不学Go语言,学多深入,够用为止还是成为专家,只会影响当前的工作效率,我们绝不会把它上升到职业生涯的高度考虑。但日积月累,那些我们一知半解的新技术逐渐成为主流,使用多年的技能能够排上用场的地方却越来越少。知识贬值就这样不知不觉地发生了。

  • 我们决策依据是当下的边际收益

为什么我们不肯花精力学好新技术呢?因为我们往往只看当前的边际收益。第一,随着收入增加和逐年积累,我们在财务上的压力越来越小,努力工作获得加薪的动力越来越弱。第二,随着工作职责的丰富,技术能力对个人工作产出的贡献降低,很多人把时间花在琢磨软技能上。第三,随着职级增加,升迁难度变大,需要的天赋和投入成倍增加,技术更新带来对继续升迁的帮助变小。而面对升职难度和职业天花板,很多人的心态也从开拓进取变成消极守成。

另一方面,生活里需要投入精力的事情越来越多。职场新人特别愿意加班,除了因为刚刚起步有很多需要学习,也因为他们的生活简单精力充足,把时间用在努力工作、升职加薪上是回报最大的选择。可是人到中年,再像年轻人一样拼搏就显得有点不划算了。生活里需要我们的人和有趣的事越来越多,把周末的时间用来加班和学习,就意味着要牺牲和爱人相处,跟朋友聚会,或者陪伴家人的时间。投资在技能更新上的边际成本变得越来越高。

学习新技术的边际收益减小,边际成本却在增加,我们很自然就会减少在技术更新上的投入。我们很难注意到自身知识资本长期变化的趋势,即使想到也倾向于把问题留给未来:也许我们会暴富从此不用担心工作,也许我们也不准备继续在这个行业长做下去,谁知道呢?

  • 从整个人生跨度看

我们对于被淘汰的焦虑大部分来自对经济能力的忧虑:人到中年,不用说却忽然失去谋生的饭碗,即使降薪也让人难以承受。另一方面,这种焦虑也是对失去价值的恐惧。处在黄金年龄的我们期待未来永远是积极向上的:股市十年长牛,工资年年增加,房子越住越大,我们无法想象这条向上的曲线有一天会掉头向下。

可是放在整个职业生涯乃至人生的跨度里,抛物线更接近人生的真相。我们也许不知道顶点在哪里,可是月盈则亏,迟早有一点我们要从顶点落下。我们当然应该努力享受在时代的浪尖上乘风破浪的感觉,可是也要做好从浪尖上退下来的准备。我们唯一的希望就是,当我们从顶点落下的时候,仍然有人爱着我们,未来的生活因为提前规划保持体面。

除了经营生活、在财务上积极准备,调整职业选择以延缓技能贬值的速度也是切实可行的策略。知识更新太快是互联网行业被优化的焦虑的根本原因,但任何行业都不是铁板一块。面向消费者的领域技术更新快,但面向企业业务的领域技术迭代就慢得多了;小型企业比如创业公司更新快,但大型稳定公司技术更新慢。

想必你已经看出来了,延缓贬值的解药就是在适当的时候进入面向企业客户的公司,进入业务稳定成熟的大公司。他们的另一个名字是:养老公司。你当然不会继续在时代的浪尖上冲浪,可那也意味这你可以将更多精力投入生活,投入给你所爱的人和事。但愿到那时,你已经在工作之外建立足够多的支柱,即使职业变动也不会降低生活的幸福感。

Book Review: The Effective Engineer

The effective engineer raise a simple question: how does the engineer leverage his or her effort to make a disproportionate and meaningful impact? Before answering the question, we would want to know how to define and measure the effectiveness of an engineer and engineering activities. The author believes that leverage, the value or impact produced per time invested, is the best measurement for the effectiveness. In order to increase your effectiveness, you should focus on either get the same task done more quickly, or to increase the impact of your activities, or to shift to activities with higher leverage.

The foremost and fundamental part of becoming more effective is to adopt the right mindset. Including focusing on high-leverage activities, optimize for learning, and prioritize regularly in order to keep yourself focused.

The following sections of this book are essentially discussing the two major approaches of increasing your effectiveness. Part II of this book focused on execution: how do you get your work done more efficiently.

The first advise it offers it to improve the iteration speed: the faster you can iterate, the more output you could generate within a given time. Many factors could slow down the iteration speed: maybe your team works on a huge monolithic service without enough support on tooling and debugging, maybe your existing service requires constant operation support that your team gets distracted. To become more effective, you should constantly think about what makes you and your team’s iteration speed slow down.

Another advice is to measure what you want to improve. A common mistake people make during work is using the wrong metric to measure the problem. Selecting the wrong metric could be misleading.

Measuring the area you want to improve also help you better drive the work. Whether you are an individual contributor, a tech lead or an engineering manager, you must be in situations when you would like to bring some technical, product work to people’s attention so that you get their consensus on the priority of the work and support to work on it. In these situations, data and metrics are more compelling than words. So the best strategy is to measure the scope of your work: how many order we lost every day due to this issue, how many customers are being affected. You will be much better off with these measures.

The third advice is to validate your ideas early and often. I’ve got multiple opportunities to start new products from scratch. I find it is very useful to deliver the first version of the product as fast as you can, collect the requirements from your customers then try to improve on it. It is very hard to picture every detail of your product before you bring it to your customer. And I give this advice to every engineer working on some project.

The fourth advice is to improve your project estimation skill. Project estimation is hard, but it is important for the team to communicate the expectation to the stakeholders, and for the business to decide the priority of these works. We made many mistakes on effort estiamation, people either tend to underestimate or overestimate the difficulties of their task, and there is an anchor effect on people’s preference. For large project estimation, this becomes even challenging,  because we oftentimes underestimate the unknown parts, and they only start to materialize once the team starts to work on them. Of course, there are approaches to reduce the risk of inaccurate effort estimation, for example, ask the people that will work on the task to do the estimation, and timebox the investigation on the unknown part.

For tech leads and engineering manager who held the responsibilities of communicating the expectation and progress to the stakeholders, the effort estimation becomes even more critical. First of all, you should define a clear goal for your project. A clearly defined goal not only helps you better manage the expectations of the stakeholders but also provides with you a good approach to correctly scope the works and prioritize the tasks.  Secondly, you should build your project incrementally. Trying to achieve multiple goals in one project can significantly increase the risk your project get slipped, as the complexity of the project grows exponentially.

Part III of this focused on building long-term value: which is the more impactful work for the engineers comparing to other activities like delivery a feature.

The advice from this section includes balancing the quality with pragmatism. An essential topic for most the engineering team is how to improve the quality of the work, except for a few companies like Google, as they introduced such a good code review system to make sure the code is written in good quality. This is not the case for most other engineering teams. Introduce the code review process will be helpful. Another such topic is about tech debt. Tech debt will be accumulated as the team takes shortcuts on the development. It is totally okay to introduce tech debt on the code base, but the team should also have a pan to continuously repay the tech debt.

The next advice is to minimize the operational burden. You must always be aware of the tech decision you make: is it engineering infrastructure you build robust enough that you don’t need to worry about its operation support? Does the tools you provide enough visibilities with the clients to track out the failures easily? Another typical mistake we make is to introduce new technology without enough knowledge about its operational burden.

The last advice is to invest in your team’s growth.  Help the people around you be successful, building a better onboarding process, making hiring a priority of the team. All these works would lead to a better engineering culture.

This book is not only a good choice for engineers who want to become more effective but also a good guide for the engineering managers to materialize their ideas of building a better team: essentially only when your team member becomes effective, you will be effective.