Fork me on GitHub

laike9m's blog

Yuri Is Justice

Google

Another Year, Another Layoff

Google 又裁员了。去年是一月份,今年也是一月份。我们都开玩笑,不如以后一月不裁员才发通知。

相比上次,我对这次裁员非常不满。23 年初经济状况看起来不好,所有公司都很悲观,裁员削减开支行我理解。但今年呢?首先,招聘已经放缓很久,相当多部门近一年都没招人了,削减过度招聘不能再作为理由。再者,即便 ChatGPT 横空出世,Google 的股价依然上涨,美国经济短期看起来也都 OK(当然隐患仍在),所以我只能理解为这次裁员是做给大股东们看的,为了展现公司的“Focus”。比如 Cloud 没裁人,那尽可以抓住这点大做文章:看,我们对云多么 focus。对公司来说,这次裁员绝对是负收益——如果去年大家还觉得裁员是不得已之举,现在变得常态化之后,所有人的不安全感都会激增,士气和动力也必然降低。说到底,还是管理者们(VP and above)为了自己手中的股票拿底层员工开刀。

稍好的一点是这次给了被 layoff 的员工转组的时间,且保留了内部招聘网站的访问权限。我只能希望想留下的人都能找到新组,但这显然是不可能的。

Google

巧合

人们总是对巧合津津乐道,比如著名的林肯与肯尼迪。前几天我才意识到巧合也发生在了自己身上。

首先需要科普一下,西班牙足球甲级联赛(以下简称“西甲”)有三支传统强队:皇马、巴萨、马竞。由于三队和其它球队差距太大,常常被球迷们称为“西超”。这其中,皇马和巴萨的球迷很多,马竞球迷则很少。而我恰好就是个马竞球迷。

随机选地球上的三个人,其中分别有一个皇马、巴萨、马竞球迷的概率是多少呢?做一下超级粗略的估算,假设一个人是皇马或巴萨球迷的概率为 1/20,是马竞球迷的概率是 1/10000,乘起来就是 1/20 * 1/20 * 1/10000 = 1/4000000,即四百万分之一。

而我们组就出现了这个情况:我(马竞)、一个俄罗斯老哥(皇马)、一个印度妹子(巴萨)。除此之外就没有球迷了,正正好好。这还不算完,更绝的是我们三个的桌子恰好挨着,像下图画的这样:

image

桌子是去年重返办公室时随机分配的。因为是 open office,我们三个的桌子不与其它任何桌相邻,形成了一个孤岛!而直到几个月后我们吃饭聊天才知道彼此都是球迷。这和大街上直接抓三个人分别是三队球迷也没啥区别了吧。这么巧的事竟然那真的能碰到,我已经不知道怎么去计算概率了。

跟女朋友讲了一下,她说因为我已经是马竞球迷,所以遇上此事的概率自然就大一些。这么一想也对。但这的确是我经历过最巧合的事了,因此记录一下。

Google

Legacy Code, Legacy Country

最近我发现软件工程和国家的演化有诸多相似之处。很多复杂的历史/政治/经济/社会问题,映射到软件工程领域后都变得好懂了。因此来分享一下这个观察世界的角度,相信程序员们会很容易接受。我姑且把它称做“软件社会学”。软件社会学不是一种(严肃的)理论,而是一种可以用来认识世界的工具。

国家和软件项目的相似性

首先也是最重要的一点,我们要意识到国家和软件项目的相似性。这里列举几点,其实还有更多:

  • 都有“生命”,且生命周期较长
  • 都在不断变化
  • 参与其中的人带来变化,变化也反过来影响每个人

解释一下第一条。有人会说我的代码还没上线项目就被毙了,生命周期哪里长了?没错,但同样也有还没诞生就夭折的国家。再者,这里的“较长”并非指绝对时长,而是相对于变化速度来说的——代码变化快,即便它只存在了几个月,也可能有几百几千次提交了。

虽然我们无法严格地把两者对应起来,但不妨先建立一个框架,后面才有的讨论。

国家的兴衰 → 代码的生长和腐化

这点相信凡是在稍具规模的项目上工作过的人都能理解。正如国家在刚建立时一般朝气蓬勃,一个项目在刚开始的时候总能快速迭代。这时候代码量和技术债都很少,改了甚至就能直接 push 上线。人也少,大家对项目和彼此都很熟悉,工作起来效率很高。

随着时间推移,项目的代码量多了起来,团队规模也越来越大(姑且假设项目很成功)。工程师们逐渐发现,原来了如指掌的代码渐渐读不懂了,经常要问同事这里怎么工作,那里为什么这么改;明明就改了一行,却 break 了不知道哪个角落的测试,而你却连这个测试在干嘛都不知道;代码规范也从一开始的统一,变成了八仙过海各显神通;合理抽象更是不存在了,大家都是能跑就行哪管那么多。

假设这时突然来了个年轻有为的程序员,大手一挥说这么干不行,我们要制定规范、改进代码质量,让开发速度重新快起来。结果呢?可能项目里的老人不鸟他,可能老板觉得他不出活,也可能只是单纯的工作量太大他完成不了——总之这种事基本没有成功的案例。国家也类似,到了末期全身都是积弊,想改也没法改了。这是不以个人意志为转移的。

社会观念/政治体制 → 软件项目的架构

这是我觉得最有意思的一个对应。我们都知道合理的系统架构对于后续开发的重要性,因为很多东西一旦确定下来后面就很难改了。国家也是类似,比如大家最熟悉的两个例子:

  • 秦始皇:中国第一架构师,提出的“大一统”架构延续了两千多年
  • 独立宣言:提出了“人人生而平等”的理念,作为美国的基石延续至今

自这些架构提出之后,虽然后人不断小修小补,提出各种不同的解读,但这些架构在社会中只会越嵌越深,以致无法被撼动。几百年几千年过去,这时候你会发现初始架构的强大之处——不管上层代码再怎么变,国家就按这个架构一直跑下去了。

应用举例:为什么完美的体制不存在?

我们都知道随着环境/需求/人员/预算等状况的变动,一个曾经很合适的架构会变得不合适(比如难以扩展),反之亦然。社会观念和政治体制也是如此,比如曾经高效的奴隶制在历史长河中就被淘汰了,这种例子不要太多。

我们还知道,软件工程里是没有银弹的,同样也没有完美的体制。总有人说美国三权分立很完美,结果 Trump 安排的三个大法官完美演示了什么叫卡系统 bug,那倒车开得叫一个快。事实就是,在一个极端复杂的系统里是不存在“完美”的,只有永恒的 trade-off。

应用举例:为什么错误的政策会造成深刻且持久的伤害?

由于人类很可悲地生活在线性的时间里,发生的事情就是发生了。错误的设计会造成深刻且持久的伤害,因为新代码会遵循这个设计编写,从而变成未来重构的负担——错误持续得越久,负担也就越大。有人形象地把改代码比作一边开车一边换车轮。事实的确如此,理性的公司都不可能抛掉老代码来个完全重写。George Hotz 在推特尝试过,但失败了,因为这事本来就不可能成。类似的,实行一个政策很容易,改掉却很难,于是错误(技术债)就这么越积越多,直到无法维持下去的那一天。

应用举例:为什么小国容易治理?

独立开发者们写代码发布新版本总是很快,因为依赖少。不论是加新功能、修bug、重构,甚至是更新架构,都相对容易。随着团队扩大,这些原本容易的事也变得困难了。

国家类似,越小的国家越容易治理,根本原因在于复杂度是和规模正相关的,甚至如果考虑内部依赖,这种复杂度的增长是指数级的。一套对小国适用的政策很可能对大国不适用——就好像你很难在 Google 这种体量的公司用创业公司的风格去工作。

应用举例:为什么美国如此强大?

美国的例子实在是太有趣了,因为它完全就是从英国这个 repo fork 出去,然后又重写的一个版本。因为是重写,所以可以抛掉君主制这个积累了几千年的技术债;因为是重写,所以 co-founder 们重新审视了一下人类历史,找到了当时最新最合理的架构;还是因为重写,奴隶制这种错误的设计没有在代码中扎根太深,因此在后续大版本中被移除,但即便这样美国也付出了沉重代价。美国历史短,但这正是它最大的优势。它就 Google 和Meta 这些曾经的创业公司一样,通过发现一块新的大陆,然后称霸全球。

然而即便是美国,技术债在二百五十年中还是不可避免地越积越多:枪支、毒品、贫富差距、社会两极化等等。人类若想找到新的灯塔,也必须通过建立新的国家——比如火星殖民、加密货币(?),但这就是另一个故事了。

总结

一旦你意识到这种对应,便会发现两者的相似性远不止文中写的这些。这种重新认识世界的过程将是个有趣的体验。

我不认为软件社会学是一种理论,因为它基于类比而非严肃的论证。我更愿意把它当做趁手的工具。工具只要能用就好,我们不用特别关心原理,也无需严格证明它的正确性。或许未来有人能深化一下把它做成一种理论,谁知道呢。


top