断舍离和独立成长

① Dead Code Lives Forever

那些不再用的代码, 通常被叫做 dead code.

每隔一段时间, 这些不用的代码会被手动清理掉. 不然, dead code会将系统变得臃肿, 难以维护, 有时候还会浪费一些计算资源.

比如, 有一些冗长的 if/else 曾几何时用来控制迭代版本的, 而多年后, 所有traffic都在最新的版本, 我们理应删掉不用的code path; 有一些 function 是当时防备一些edge case的, 而多年之后, 这些边角问题早就不存在, 我们没必要维护这些附加功能 … etc.

既然是没用的代码, 留你何用? 为什么不删除? 你怎么想?

  • What Doesn’t Break, Don’t Fix It: 工作时, 大家一般不太想碰这些代码. 等出了问题, 报错了, 才会引起人的重视, 再删不迟

  • Perceived Value: 再次遇见那一坨不用的代码, 我们很可能给出保守的判断: 这块代码, 未来可能还用, 是不是该留着?

  • Identity and Self-Worth: 若是一串引以为傲的代码, 即便真的用不到了, 心理上肯定还有一点阻力: 是不是删掉了就意味着之前的功夫白费? 是不是就意味着之前的付出是无效的?

  • Additional Efforts: 删除dead code也并不总是轻松: 我们还是要测试, 还是要验证’没用’的假设, 花好一番功夫. 在效率至上的工作环境里, 谁会无缘无故花几个小时给代码瘦身?

基于这些因素, dead code 很快就会积累起来, 让一个工程团队变得行动迟缓. 应对这个问题的方式, 当时还是从这个团队里面的人着手: 给清理工作带上光环, 让大家愿意做清理工作, 崇尚整齐有序的code base - 再一些公司里面, 这类工作可以被称作 Better Engineering, 或者概括为Best Practices.

每过一段时间, 工程师们会自发地组织起来, 清理dead code, 并且对此举引以为傲. 试想, 不久后的将来: AI对工程师的一大帮助, 可能是有序地建议dead code 清理, 并且做好测试, 让工程师更便捷地规整code base.

② Cutting Junks

近几年, 我有几次断舍离的机会.

Physical Junks

在西雅图, 我曾经有一个储藏间, 在里面存放着从2010 - 2020, 十年多的物件: 大学的铅笔笔记, 旧衣物, 旧家具, 主机箱, 损坏的电脑, 乐队杂物, 纪念品, EE硬件零碎, …etc.

这场清理会让人走一遍memory lane: 曾经的笔记, past relationship, 硬件零部件, 每个阶段认为”贵重”的东西.

最后我决定留下的只有小小的memory box, 里面的东西很基本上没有什么经济价值, 不过有一定的情绪价值

Digital Nomad - Minimum Household

数字游民的那两年, 每次离开一个地方 (湾区, 夏威夷, 阿拉斯加, 纽约, 西雅图), 我们也被迫做一次清理; 想带着的只有两三个行李箱, 一个吉他.

在买新东西时候, 都会考虑是不是真的需要, 能不能带走? 就算要买: 离开时候, 哪些家具可以卖掉? 哪些价格便宜可以捐掉?

绕了一大圈2022年回到湾区, 我的想法已经很不同. 打开2020离开时启用的仓库: 沙发, 桌子, 衣服 … 存了一年多的东西, 最后拿出来全部卖掉, 捐掉.

当时以为需要留的东西, 其实后来都不那么重要.

Digital Junks

Google跟很多大学有过协议, 我的大学也不例外, 用了Google Workspace (Gmail, Google Drive…etc). 虽然毕业很多年, 但学校的Google邮件都保留着, 我从没有想过要清理.

从2023年开始, 谷歌开始开始终止跟一些学校的协议; 7/1/2024, 谷歌正式跟我之前大学解约. 这意味着我需要把过去的资料备份转移.于是我又走了一遍memory lane: 当年的项目, 资料, 邮件, 全部复制一份到自己的Google 账号.

目前, 我的Google Plan扩展到10TB ($50 / month), 很自然地, 我又要开始一轮切割, 把这些不需要的文件删除掉, 解约储存资源.

为什么会积累废品?

对于那些不用的东西, 有可能带有情感依赖, 象征自我价值, 或者暗示未来需求. 我们有日渐扩大的生活空间, 或者网络储蓄空间, 给这些”废品”提供了积压的余地.

这些物品随着时间推移, 对于我们个人的独立存在讲变得越发不重要. 比如, 10年前你可能维护着二十几份精湛的课堂笔记; 那种做事的条理性会变成习惯, 但我们并不需要那些笔记本身, 更不需要完整4年的笔记来见证这段过往.

别人记住我们的, 和我们记住别人的, 都是仅仅是那些精彩的瞬间. 我们既然不活在过去, 那么抓住重点就足够了.

③ Mental Burden: Should I Be Responsible For All?

原生家庭

很多年, 在潜意识里, 家人的状态好像是我的责任. 反观我的童年, 这似乎是文化给小孩子的一个枷锁: “你的父母家人很辛苦, 所以你千万不要惹他们生气, 这样你们一家人才会好”.

看似一个合理的连带关系, 实则一种枷锁. 如果父母的幸福需要小孩子来维护, 那是不是颠倒了父母和孩子的身份? 如此一来, 小孩子反倒要照顾父母的喜怒哀乐, 而父母也失去了施加关爱的能力? 这种逆向的关系并不会因为孩子成年而解锁.

这个想法来自于一支podcast: Morden Wisdom (Chris Williamson); 同时他也是我想尝试podcast的灵感起源.

一个episode里, 嘉宾提到自己一直背负这样的心里压力: being responsible for others’ happiness. 而他人不幸福快乐的时候, 他也会有一定的负罪感. 反过来说, 也是一种自我价值的依赖: 当他们也需要我, 我才有在这个家庭合理存在的意义.

这种潜在的反向依赖, 在personal relationship和工作里面都会体现.

团队

工作了很多年以后, 我很清楚地感觉到一种’脱不开工作’的状态.

仿佛很多时候没你不行: 不管谁oncall你都要在线, 不管是什么报错, 你都需要心理有数; 一些同事能不能做出成绩升职加薪, 你都要有一定的担当. 这些可能是一个leader应该承担的, 但这也可能演化成一种无法scale的状态.

是不是说, 这种’负责任’的心理状态, 也是那个”自我存在意义”的衍生? 我们必须对他人提供更多的价值, 这样我的存在才更加合理?

但是反过来想: 如果所有的burden都由一个人来背, 队友是不是没了机会成长? 如果难题都等某一个人解决, 那是不是变成了团队的瓶颈? 如果每个人的成长都牵连到某一个TL的能力, 是否也意味着过大的风险.

Trusting others to do the right thing. 一段时间以后, 我开始努力把一些重要的位置空出来给别人: 一部分backend比较晦涩的难题, A来扛一扛; 一部分frontend的全新技术栈, B来主导一下设计. 就我目前观察, 这些承担更多责任的队友, 似乎比过去更主动积极.

建立独立的心理状态是挺独特的一种体验: 对同事, 我们共同承担着责任; 在特定的时候, 我需要把机会给别人准备好, 但是每个人是不是能够独立解决挑战, 独立成长, 有时候要取决于他们个人的天时地利.