Google 又裁员了。去年是一月份，今年也是一月份。我们都开玩笑，不如以后一月不裁员才发通知。
相比上次，我对这次裁员非常不满。23 年初经济状况看起来不好，所有公司都很悲观，裁员削减开支行我理解。但今年呢？首先，招聘已经放缓很久，相当多部门近一年都没招人了，削减过度招聘不能再作为理由。再者，即便 ChatGPT 横空出世，Google 的股价依然上涨，美国经济短期看起来也都 OK（当然隐患仍在），所以我只能理解为这次裁员是做给大股东们看的，为了展现公司的“Focus”。比如 Cloud 没裁人，那尽可以抓住这点大做文章：看，我们对云多么 focus。对公司来说，这次裁员绝对是负收益——如果去年大家还觉得裁员是不得已之举，现在变得常态化之后，所有人的不安全感都会激增，士气和动力也必然降低。说到底，还是管理者们（VP and above）为了自己手中的股票拿底层员工开刀。
稍好的一点是这次给了被 layoff 的员工转组的时间，且保留了内部招聘网站的访问权限。我只能希望想留下的人都能找到新组，但这显然是不可能的。
人们总是对巧合津津乐道，比如著名的林肯与肯尼迪。前几天我才意识到巧合也发生在了自己身上。
首先需要科普一下，西班牙足球甲级联赛（以下简称“西甲”）有三支传统强队：皇马、巴萨、马竞。由于三队和其它球队差距太大，常常被球迷们称为“西超”。这其中，皇马和巴萨的球迷很多，马竞球迷则很少。而我恰好就是个马竞球迷。
随机选地球上的三个人，其中分别有一个皇马、巴萨、马竞球迷的概率是多少呢？做一下超级粗略的估算，假设一个人是皇马或巴萨球迷的概率为 1/20，是马竞球迷的概率是 1/10000，乘起来就是 1/20 * 1/20 * 1/10000 = 1/4000000，即四百万分之一。
而我们组就出现了这个情况：我（马竞）、一个俄罗斯老哥（皇马）、一个印度妹子（巴萨）。除此之外就没有球迷了，正正好好。这还不算完，更绝的是我们三个的桌子恰好挨着，像下图画的这样：
桌子是去年重返办公室时随机分配的。因为是 open office，我们三个的桌子不与其它任何桌相邻，形成了一个孤岛！而直到几个月后我们吃饭聊天才知道彼此都是球迷。这和大街上直接抓三个人分别是三队球迷也没啥区别了吧。这么巧的事竟然那真的能碰到，我已经不知道怎么去计算概率了。
跟女朋友讲了一下，她说因为我已经是马竞球迷，所以遇上此事的概率自然就大一些。这么一想也对。但这的确是我经历过最巧合的事了，因此记录一下。
最近我发现软件工程和国家的演化有诸多相似之处。很多复杂的历史/政治/经济/社会问题，映射到软件工程领域后都变得好懂了。因此来分享一下这个观察世界的角度，相信程序员们会很容易接受。我姑且把它称做“软件社会学”。软件社会学不是一种（严肃的）理论，而是一种可以用来认识世界的工具。
首先也是最重要的一点，我们要意识到国家和软件项目的相似性。这里列举几点，其实还有更多：
解释一下第一条。有人会说我的代码还没上线项目就被毙了，生命周期哪里长了？没错，但同样也有还没诞生就夭折的国家。再者，这里的“较长”并非指绝对时长，而是相对于变化速度来说的——代码变化快，即便它只存在了几个月，也可能有几百几千次提交了。
虽然我们无法严格地把两者对应起来，但不妨先建立一个框架，后面才有的讨论。
这点相信凡是在稍具规模的项目上工作过的人都能理解。正如国家在刚建立时一般朝气蓬勃，一个项目在刚开始的时候总能快速迭代。这时候代码量和技术债都很少，改了甚至就能直接 push 上线。人也少，大家对项目和彼此都很熟悉，工作起来效率很高。
随着时间推移，项目的代码量多了起来，团队规模也越来越大（姑且假设项目很成功）。工程师们逐渐发现，原来了如指掌的代码渐渐读不懂了，经常要问同事这里怎么工作，那里为什么这么改；明明就改了一行，却 break 了不知道哪个角落的测试，而你却连这个测试在干嘛都不知道；代码规范也从一开始的统一，变成了八仙过海各显神通；合理抽象更是不存在了，大家都是能跑就行哪管那么多。
假设这时突然来了个年轻有为的程序员，大手一挥说这么干不行，我们要制定规范、改进代码质量，让开发速度重新快起来。结果呢？可能项目里的老人不鸟他，可能老板觉得他不出活，也可能只是单纯的工作量太大他完成不了——总之这种事基本没有成功的案例。国家也类似，到了末期全身都是积弊，想改也没法改了。这是不以个人意志为转移的。
这是我觉得最有意思的一个对应。我们都知道合理的系统架构对于后续开发的重要性，因为很多东西一旦确定下来后面就很难改了。国家也是类似，比如大家最熟悉的两个例子：
自这些架构提出之后，虽然后人不断小修小补，提出各种不同的解读，但这些架构在社会中只会越嵌越深，以致无法被撼动。几百年几千年过去，这时候你会发现初始架构的强大之处——不管上层代码再怎么变，国家就按这个架构一直跑下去了。
我们都知道随着环境/需求/人员/预算等状况的变动，一个曾经很合适的架构会变得不合适（比如难以扩展），反之亦然。社会观念和政治体制也是如此，比如曾经高效的奴隶制在历史长河中就被淘汰了，这种例子不要太多。
我们还知道，软件工程里是没有银弹的，同样也没有完美的体制。总有人说美国三权分立很完美，结果 Trump 安排的三个大法官完美演示了什么叫卡系统 bug，那倒车开得叫一个快。事实就是，在一个极端复杂的系统里是不存在“完美”的，只有永恒的 trade-off。
由于人类很可悲地生活在线性的时间里，发生的事情就是发生了。错误的设计会造成深刻且持久的伤害，因为新代码会遵循这个设计编写，从而变成未来重构的负担——错误持续得越久，负担也就越大。有人形象地把改代码比作一边开车一边换车轮。事实的确如此，理性的公司都不可能抛掉老代码来个完全重写。George Hotz 在推特尝试过，但失败了，因为这事本来就不可能成。类似的，实行一个政策很容易，改掉却很难，于是错误（技术债）就这么越积越多，直到无法维持下去的那一天。
独立开发者们写代码发布新版本总是很快，因为依赖少。不论是加新功能、修bug、重构，甚至是更新架构，都相对容易。随着团队扩大，这些原本容易的事也变得困难了。
国家类似，越小的国家越容易治理，根本原因在于复杂度是和规模正相关的，甚至如果考虑内部依赖，这种复杂度的增长是指数级的。一套对小国适用的政策很可能对大国不适用——就好像你很难在 Google 这种体量的公司用创业公司的风格去工作。
美国的例子实在是太有趣了，因为它完全就是从英国这个 repo fork 出去，然后又重写的一个版本。因为是重写，所以可以抛掉君主制这个积累了几千年的技术债；因为是重写，所以 co-founder 们重新审视了一下人类历史，找到了当时最新最合理的架构；还是因为重写，奴隶制这种错误的设计没有在代码中扎根太深，因此在后续大版本中被移除，但即便这样美国也付出了沉重代价。美国历史短，但这正是它最大的优势。它就 Google 和Meta 这些曾经的创业公司一样，通过发现一块新的大陆，然后称霸全球。
然而即便是美国，技术债在二百五十年中还是不可避免地越积越多：枪支、毒品、贫富差距、社会两极化等等。人类若想找到新的灯塔，也必须通过建立新的国家——比如火星殖民、加密货币（？），但这就是另一个故事了。
一旦你意识到这种对应，便会发现两者的相似性远不止文中写的这些。这种重新认识世界的过程将是个有趣的体验。
我不认为软件社会学是一种理论，因为它基于类比而非严肃的论证。我更愿意把它当做趁手的工具。工具只要能用就好，我们不用特别关心原理，也无需严格证明它的正确性。或许未来有人能深化一下把它做成一种理论，谁知道呢。
