Weekly#32

当我还是个孩子时，我的祖母有一个广阔的花园，里面种满了西红柿、黄瓜和向日葵。

每个生长季节，她都会花几个小时照料她的植物，给它们浇水、修剪，甚至像对待老朋友一样和它们说话。

我记得曾经问她：“你为什么这么辛苦地照顾这些植物？它们甚至不会说谢谢。”

她笑着说：“哦，但它们会的。它们养活我们，给我们遮荫，让世界变得美丽。

到底是谁在为谁工作呢？”

Source

请考虑这一点： 植物已经存在了超过 5 亿年。

它们经历了大规模灭绝、冰河时代以及无数其他灾难。

人类则只存在了几十万年。

在地球历史的宏大时间线上，我们是新来的孩子。

然而，我们却投入了大量时间和精力来栽培植物。

我们开垦土地用于农场，建造温室，基因改造作物以使其更具韧性和产量。

从某种角度看，几乎像是我们在为它们工作。

Source

还有水果的例子。苹果、香蕉、草莓。

这些都是美味且富含营养的人类难以抗拒的食物。

但水果不仅仅是为了我们。

它们是一种巧妙的进化策略。

通过使自己美味可口，植物确保动物（包括人类）会吃掉它们并传播它们的种子。

换句话说，我们实际上是它们繁殖过程中的无偿劳工。

我们吃水果，携带种子到新的地方，并将它们埋在富含养分的土壤中。

这是一个绝妙的系统，而我们已经被它迷惑了数千年。

Source

在他的著作《欲望的植物学 (The Botany of Desire)》中，Michael Pollan 深入探讨了这一观点。

他认为，像苹果、郁金香、大麻和土豆这样的植物操纵人类去传播和栽培它们，就像花朵操纵蜜蜂一样。

“真正的问题，” Pollan 写道，“不是我们是否在操纵植物，而是植物是否在操纵我们。”

Source

那么，植物是在“种植”我们吗？

这是一个发人深省的观点，挑战了我们对自然世界的假设。

我们喜欢认为自己是主导物种，是掌控一切的存在。

但事实是，我们与周围的植物紧密相连。

它们为我们提供生命的必需品，而作为回报，我们帮助它们繁荣和传播。

也许这里真正的教训是谦卑。

我们不是自然的主宰；我们是其中的一部分。

如果植物一直在“耕作”我们，也许这并不是一件坏事。

毕竟，它们已经做了数百万年，而且做得相当不错。

也许是时候停止把自己看作与自然世界分离的存在，开始认识到我们在其中的位置了。

Source

熵在多个学科中有多种正式定义——热力学、统计力学、信息论——但它们都共享一个核心思想： 熵量化不确定性 (entropy quantifies uncertainty)。

Source

[…]

通过这个，我们可以发现一个表示概率为 p 的状态所需信息比特数的公式。

$I(p)=-{\text{log}}_2(p)$

这个值 I 通常被称为信息量或惊喜度，因为状态发生的概率越低，当它发生时惊喜越大。

当概率很低时，惊讶度很高；当概率很高时，惊讶度很低。

[…]

熵不一定是表示系统所用比特数的期望值（尽管在使用最优编码方案时是这样），更一般地说，熵是系统的期望惊讶度。

[…]

希望现在更直观一些， 熵代表不确定性。

一个八面骰子的熵会比一枚硬币高，因为我们对八面骰子的结果更加不确定。

但一个极不公平的八面骰子的熵甚至比硬币还低，因为我们对这个不公平骰子的结果非常确定。

Source

在统计力学中，大尺度测量的正式术语是宏观态 (macrostate)，而能够满足该测量的具体状态是微观态 (microstates)。

我们会将测量盒子两侧球的数量称为宏观态，而各个球的位置不同组合则是微观态。

换句话说：只有一个微观态代表所有球都被计数在一侧的宏观态，而有许多微观态代表平衡盒子的宏观态。

Source

熵不仅仅是物理系统本身的固有属性，更是我们对其描述的属性——即我们所测量的宏观状态以及观察它的分辨率。

Source

[…]

当我们允许更多的微观状态来表示同一宏观状态时，我们对系统所处的微观状态的不确定性就更大。

但这个结果确实引发了一些担忧。

如果不同的微观状态给出不同的熵，我们如何选择适合我们问题的微观状态？

与宏观状态不同，选择使用哪些微观状态并不是由我们的仪器或问题的范围决定的，而必须由进行计算的人来决定。

对于物理系统，人们通常会使用能够捕捉与宏观状态相关的所有重要信息的微观状态集合。

例如，如果我们的宏观状态是关于盒子左侧或右侧的球，那么我们可能不关心球的速度、质量或其他任何东西，只关心球的位置。

另一个问题是，同一个物理系统在相同的宏观状态下，根据我们使用的微观状态表示方式，熵值可能不同，这让人感觉不对。

通常，我们期望物理系统的测量结果不受我们选择的内部表示方式影响而保持不变。

但对于熵来说，这种想法是错误的。

我们需要记住，熵是系统的不确定性，而熵的定义完全依赖于我们不确定的内容，对于物理系统来说，就是微观状态。

这类似于有人问“那台机器由多少个部件组成？”，我们应该回答“你如何定义‘部件’？”。

当我们问“这个宏观状态的熵是多少？”时，我们需要回答“我们使用的是哪些微观状态？”。

Source

当你把一滴牛奶滴入茶中时，它总是扩散并混合，但你从未见过牛奶分子自发地分离并回到整齐的水滴状态。

当海浪拍打岸边时，水花和泡沫四散，但我们从未见过那种混乱重新组合成一个连贯的波浪并重新冲向大海。

这些例子取自 Richard Feynman 关于熵的讲座。

如果有人给你看这些事件的倒放视频，你会立刻察觉有什么不对。

这乍一看很明显，但实际上如果我们仅仅观察物理定律，这并不清楚应该是这样。

所有已知的物理定律都是时间可逆的（波函数坍缩似乎存在争议），这意味着它们正放和倒放看起来是一样的。

单个分子都遵守这些时间可逆的定律，然而茶杯中的牛奶总是混合使茶变得浑浊。

这突显了一个根本的悖论：微观物理定律是时间可逆的，但宏观世界却不是。

如果你拍摄两颗原子相互碰撞的视频并倒放，它看起来仍然符合物理规律，但如果倒放牛奶与咖啡混合的视频，显然就不对劲了。

Source

关键在于粗粒化 (coarse-graining)。

当我们观察世界时，我们看不到每一个微观细节。

相反，我们测量宏观状态：诸如温度、压力、物体位置或一杯茶中颜色分布等聚合属性。

每个宏观状态对应许多潜在的微观状态——而且并非所有宏观状态都是平等的。

[…]

如果你对宇宙中所有粒子有完美的了解（即你处于微观状态的层面），时间看起来就不会有方向感。

但从像我们这样的粗粒度观察者的角度来看，熵倾向于增加。

这就是为什么茶水混合的电影看起来自然，而反过来看则显得假。

在物理定律层面，两者都是有效的。

但一个是典型的，另一个则极其罕见，这一切都是因为我们进行了粗粒度处理。

Source

随着时间的推移，系统自然会倾向于探索最可能的宏观态，因为最可能的宏观态拥有更多的微观态供你漫游。

也就是说，熵随时间增加，并不是因为定律中存在任何根本的不可逆性，而是因为高熵宏观态更加典型。

如果我们从模拟开始时所有球都堆积在左侧，那是一个非常特定的（低熵）宏观态。

随着它们扩散，兼容的微观态数量增加，熵也随之增加。

这导致了一个关键的认识：熵增加是因为我们起初处于一个低熵状态。

这通常被称为过去假说 (Past Hypothesis)，即宇宙起始于一个极低熵状态的假设。

基于此，热力学第二定律 (Second Law of Thermodynamics) 自然而然地成立。

时间之箭并非源自动力学本身，而是源自在粗粒化之后逆转动力学的统计不可能性，以及我们起初处于低熵状态的事实。

你可以想象，一旦一个系统达到接近最大熵的状态，它看起来就不再具有时间不可逆性。

Source

局部的熵减少是可以产生的，只要整个系统的熵仍在增加。

Source

熵有时被描述为“无序”，但这个比喻不够准确且常常具有误导性。

在统计力学中，熵有一个严格的定义：它量化了与给定宏观态相兼容的微观态数量。

也就是说，熵衡量了在给定某种粗粒度的宏观描述下，我们对系统精确微观配置的不确定性。

那么，“无序”这一概念从何而来呢？

经验上，我们称为“无序”的宏观态通常对应着远多于“有序”状态的微观态数量。

例如，在孩子的房间里，玩具随机散落的配置远多于所有东西整齐摆放的配置。

由于散乱的房间对应更多的微观态，因此它具有更高的熵。

但熵与无序之间的这种联系并非根本性的。

问题在于“无序”是主观的——它取决于人的感知、情境和标记。

例如，在我们之前提到的 1000 个球在盒子中弹跳的例子中，一个完全均匀的球网格由于实现它的微观状态数量巨大，熵值会很高。

然而对于人类观察者来说，这样的网格可能看起来非常“有序”。

关键点是：熵是客观且在给定宏观状态和一组微观状态时定义明确的，而“无序”是一个以人为中心的启发式概念，有时但并非总是与熵相符。

依赖“无序”来解释熵可能导致混淆，尤其是在视觉对称性或规律性掩盖了潜在统计结构的系统中。

Source

那是因为幼儿不理解什么是争论，也不感兴趣去争论。

幼儿（包括防御性的官僚、欺凌者、地平说信徒、坚持特定议程的人以及广播脱口秀主持人）可能会表示他们想要争论，但他们实际上是在进行连接、制造噪音、表演或争取地位。

处于对立面、责难别人甚至用权力改变他人立场，有时也挺有趣的。

争论应该是观点的交流，旨在激发洞见并得出结论。

如果你经常与有良好意愿且知识渊博的人争论，你很可能会“输”掉一半——因为你会根据所学改变自己的想法。

如果你没有改变想法，很可能你实际上并没有真正争论（或者你交往的人不对）。

虽然改变别人的立场可能很有趣，但学到足够多以改变自己的观点也是一种礼物。

幼儿表面上是在争论，但他们实际上是在积攒发脾气的情绪。

如果他们“赢”了争论，就不需要发脾气；

如果输了，他们可以告诉自己自己已经尝试过了，但对方不听话，所以对方才该被发脾气。

“告诉我你因为类似的讨论而改变过的其他坚定立场……”这是开启你想进行的争论的直接方式。

“什么样的信息会让你有可能以不同的方式看待这个问题？”

争论我们选择作为身份一部分而信仰的事情可能没有意义。

Source

令人惊讶的是，在整个过程中我似乎一张照片都没拍。

事实上，我还得回去拍一张那屏幕的照片来写这篇文章。

人们常说我们这一代人沉迷于拍摄一切和无关紧要的东西，但显然我不属于那种类型。

不过如果我真是那样的话，现在会方便很多。

Source

现在，电力并不是“怪物”：你可以安全地打开电源供应器，只要你了解里面的危险。

首先，绝不要在电源运行时打开它：如果不小心触碰到高压部件，你可能会丧命。

然而，即使你先拔掉电源，这也不意味着它是安全的，因为里面有这些东西：

电容器。

电容器可以长时间储存电荷，所以不要碰。

它可能不会致命，因为电容器实际上储存的能量并不多，但这不意味着它不会致命，所以，别碰！

Source

据我所知，每一个 AI 成功案例都离不开熟练的人类开发者。

因此，我认为可以肯定地说，我们还没有进入“后开发者时代”。

Source

但它并不完美。

它需要指导。

这感觉有点像在高速公路上使用“定速巡航”：车子大部分时间会按照你指的方向行驶，但你仍然需要手握方向盘，保持稳定。

否则，车子会慢慢开始偏离车道。

如果你不时地轻轻调整回正轨，最终会掉进沟里。

这对“开发者将不复存在”的理论来说是个问题。

如果我不会编程，我不会注意到模型输出中那些微妙但关键的问题。

我也不会知道如何纠正方向，甚至不会意识到需要纠正方向！

Source

如果你是一个有抱负的开发者，无论是在大学、训练营还是自学，我仍然完全相信当你准备进入职场时，会有机会等着你。

在我看来，软件开发距离完全自动化还有很长的路要走。

一旦公司意识到 AI 作为开发者的辅助工具比作为开发者的替代品效果更好，我认为他们会停止自我阻碍增长，开始以更积极的速度招聘。

Source

我也有点担心下一代开发者。

使用 LLM (Large Language Model) 代理时，很容易陷入恍惚，不断点击“接受更改”，却不理解甚至不查看生成的代码。

另一方面，如果你主动使用 LLMs，现在是学习编程的最佳时机。

当我遇到不理解的 TypeScript 错误时，AI 通常能帮助我理解，或者至少提供我需要的相关关键词，以便找到正确的文档。

就像我们每个人都有一个私人导师，帮助我们理解不懂的内容。

Source

当你的测试难以编写时，系统设计中很可能存在缺陷。

这会对你施加一种“压力”，促使你去质疑过去所做的选择。

Source

让一个对问题有上下文了解的机器来写测试比我们自己写要容易得多。

但这样做，我们是否剥夺了自己学习和改进设计的机会？

Source

总的来说，我并不认为这里有非黑即白的解决方案；当然，有时候快速编写代码是值得权衡的。

与此同时，我想挑战我的工程师同仁们，下次遇到棘手问题时，不要急于求助于 LLM。

暂时的不适可能是作为工程师宝贵的成长机会。

Source

整个“vibe coding”现象再次提醒我们，很多从事技术工作的人并不理解程序 (program) 和产品 (product) 之间的区别。

对我来说，程序就是“只在我机器上能运行”的代码。

我们许多人每周都会写几次这样的东西。

实验、原型……那个你写来批量重命名文件夹中所有 MP4 文件的脚本？

你知道的那个。

没有错误检查。路径写死了。能在 Windows 上运行吗？谁在乎呢？我现在用的是 Linux，我有工作要做。

我每天都用几十个这样的程序。

它们是我用来自动化工作中某些环节的工具。

它们经常崩溃（“什么？哦……那个人的演示标题里有反斜杠……有趣。”）⸺ 但这无所谓；我修复它们，得到我需要的结果，然后继续前进。

代码只是达到目的的手段，结果才是关键。

如果你写的软件是打算发布的；分发给其他人，甚至可能卖给付费客户？那可就是完全不同的游戏了。

我职业生涯中学到的最重要的一课，也是我认为“经验”的标志，就是理解将一个可运行的程序转变为一个可行产品需要付出多少工作。

这也是为什么开发者的估算总是出奇地乐观 ⸺ 而有经验的开发者却出奇地愤世嫉俗。

假设你写了一段代码，可以从网页表单获取响应并将其添加到 Excel 电子表格中。

这并不难……耶！我们下午就做出了一个 Typeform 的竞争对手！但不，你没有。

你只是让一件事在一台电脑上运行了一次。

你没有考虑编码、国际化、并发、认证、遥测、计费、品牌、移动设备、部署。

你还没遇到任何奇怪的限制 ⸺ 有没有遇到系统在前 65,535 个请求运行良好后崩溃的情况？

你没有产品。

充其量，你只有一个好点子的概念验证，如果一些非常聪明的人非常努力，可能会变成一个可行的产品。

关于像 Copilot 和 ChatGPT 这样的工具，真正积极的一点是它们让几乎没有开发经验的人也能创建自己的程序。

小程序能做有用的事情 ⸺ 这真是太棒了。

祝用户们更有力量。

但那不是产品开发，那是编程。

它们不是一回事，甚至相差甚远。

Source

当你试图在生活中做出持久改变时，要对诸如“21 天法则”之类的普遍说法保持谨慎。

错误的观念如果被反复传播，就会被当作事实接受，但这并不代表它们是真的。

所以，请做好研究，以设定现实的期望，避免未来的失望。

Source

就我个人而言，我不会太在意 21 天法则，甚至不会太在意 Lally 的研究。

在我多年的个人转变研究中，我意识到概括往往具有误导性。

归根结底，不管你是花 21 天、66 天还是一千天来养成一个新习惯，这并不重要。

重要的是你对实现改变的决心。

此外，我们每个人都不同，环境也各异，所以不可能有一个适用于所有人的时间表，即使那只是一个指导原则。

[…]

无论生活多么混乱和艰难，你都是自己行为的主人。

你决定习惯何时、何地以及如何形成，所以专注于“为什么”，其他一切都会顺理成章。

新习惯不应该有时间表……完全不应该有。

Source

通常，加快大周期的方式是通过加快小周期来实现的。

如果你只关注加快大周期，结果的质量往往会受到影响。

例如，假设我看到一个团队需要两周时间才能将任何更改发布到生产环境。

如果我只是进去说，“无论如何都要更快发布”，而不说其他任何话，那么团队很可能会以牺牲最终结果质量和软件可维护性的方式来走捷径。

Source

另一方面，只要你确实发现了问题，加快较小迭代的速度总是安全的。

Source

软件开发是一项需要长时间深度专注才能成功完成的活动。

开发者正在构建他们正在处理的事物的非常复杂的心理结构，并利用该心理结构做出决策和编写代码。

他们不断地思考（或在笔记中写下）“哦，别忘了在完成这件事后做那件事。”

这种专注状态通常被称为“进入心流”。

当开发者被过度或频繁打断时，这种复杂的心理结构会消失，回到任务时必须重新构建。

他们有可能忘记脑海中“接下来要做的事”，并因此实际发布了有缺陷的软件。

我们称这种打断为“上下文切换”，即开发者的注意力主要转移到了编写代码以外的事情上。

当你强制开发者进行上下文切换时，他们可能需要十到十五分钟才能完全重建专注编码时的心理结构。

因此频繁的小打断代价非常高。

Source

根据我的经验，如果中断引发了负面情绪反应，干扰会更加严重。

对某事感到不快会让人分心，难以继续专注于正在做的工作。

你会觉得必须对这种不快做些什么，或者至少会一直想着它。

如果有人给我发了一条令人不快的信息，或者我的某个工具表现得极其令人沮丧，即使中断只有 5 秒，也会打断我的专注。

Source

另一个关键点是：开发者是否清楚他们正在做的工作的目的，并有明确的方向？

也就是说，我是否被赋予了一个明确的任务，知道为什么要做这个任务，它是为谁做的，以及预期的结果是什么？

否则，我自己的困惑经常会打断我的专注。

我不得不不断问同事我应该做什么。

我会坐在那里思考我的任务，而不是实际去做它。

此外，由于我没有所有做出良好决策所需的数据，我可能不会构建出最好的东西。

“认知负荷”是一个我不太喜欢的术语，因为它的含义不够明确。

就开发者体验而言，我们说这个词时的意思是：

• 开发者为了完成一项任务需要知道多少内容？
• 开发者在执行任务时被迫做出多少决策？

Source

有许多人认为开发者应该尽可能多地了解他们正在做的事情，我也同意这一点。

然而，通过减少他们必须了解才能完成任务的内容，开发者的生产力和体验得到了显著提升。

Source

开发者只需做出他们必须做出的选择。

有些开发者认为他们必须被允许对系统的每一个选择做出决定——使用什么编程语言、使用哪个包管理器来安装依赖、使用什么构建工具、代码如何缩进、使用什么监控系统、使用什么部署系统等等。

我理解这一点 ⸺ 我对自己喜欢的东西也有强烈的看法。

但大多数时候，这样的决定实际上只是迫使团队去做本不该做的工作 ⸺ 这些工作分散了他们完成核心任务的注意力。

Source

然而，必须非常小心地遵循这一原则 ⸺ 开发者需要被允许做出他们需要做的决策。

我看过很多人编写代码，每个人使用编辑器和周边工具的方式都大不相同，因为人们的思维方式差异很大。

你不能对某些工作流程的部分施加过多硬性限制，因为这会极大地损害生产力，而对整个业务没有实质性好处。

我从未见过公司说“每个人都必须使用这个编辑器”有什么好结果。

我见过的好做法是，“我们会为某个编辑器提供更多支持，但仍以命令行工具的形式暴露所有功能，这样你可以使用任何你想用的工具。”

Source

另一件你必须小心的事情是，如果你的基础设施限制了开发者可以做出的决策，你需要非常好地集中维护该基础设施。

也就是说，一个中央团队需要做出这些决策，并持续对结果负责。

Source

做好这件事的关键是深入理解开发者的需求以及他们所使用系统的需求。

你需要深入了解他们所解决的问题类型，这样才能知道哪些决策是必须做的，哪些是不必要的。

同时，你还需要能够随着时间的推移适当调整这些政策，而不是放任一切，导致混乱。

事实是，大多数开发者并不想对他们的系统做出每一个决定，然后被迫在开始任务之前完成大量自定义的底层工作。

他们喜欢编程，是因为他们可以告诉计算机去做某件事并让它执行，而且他们享受解决帮助用户的问题。

让他们专注于完成所需的任务，而不是软件工程整个宇宙中所有其他可能的决策或任务。

我在 推理与选择 (Reasoning and Choice) 中详细讨论了这一点，包括这一原则如何使得推理系统变得更加容易。

这是任何软件系统最重要的方面之一：能够在不运行系统的情况下推理其行为，而减少选择的原则有助于实现这一点。

请注意，我上面主要是从基础设施层面的选择来谈论这个问题，因为如果你是一个专注于开发者体验的核心团队，这通常是最重要的，但这一原则的适用范围很广。

在团队内部，你可以说“这些是我们的代码模式，请不要使用其他模式”，（只要这不会限制必要的选择）。

在开发工具时，你可以设置合理的默认值，这样人们就不必对工具允许的每一个选项都做出决定。

这个原则可以应用于许多许多领域。

Source

这里最重要的是要知道，问题来自用户，解决方案来自系统的开发者。

你绝不能颠倒这个关系，让用户告诉你该构建什么解决方案，而你去构建它，而开发者则坐在那里想象没人真正告诉过你他们有的问题。

如果你从事开发者体验工作，开发者就是“用户”，而你就是“开发者”。

Source

在你构建了某样东西之后，寻求关于系统的数据和反馈非常重要。

尽管我们热爱自己所构建的东西，但我们应该始终寻找开发者遇到的问题，以便我们能够解决它们——包括我们刚刚制作的东西存在的问题！

这最终会随着时间的推移为公司创造最佳的开发者体验。

Source

当你收到非常严厉的反馈时，处理的关键是：让用户知道他们的声音被听到了。

如果你的工具确实存在缺陷，就和用户达成共识！

你不必贬低自己或自己的工作，只需诚实地说明你所负责的东西的现状。

用户实际上会更尊重你，当你愿意说“是的，我同意这不是一个好的体验”时。

这并不意味着你必须立刻修复——你的团队会自行设定优先级。

只要让人们知道他们的意见被听取了，他们的抱怨是合理的，很多噪音就会平息。

有时候，人们在你听过并理解了他们的痛苦之后，仍然会继续表现得很刻薄，在这种情况下，你实际上应该告诉他们这样做是不对的，如果他们继续这样做，就和他们的经理谈谈。

不过，只有极少数人会这样表现。

绝不要把这作为你对反馈的第一反应。

Source

在美国长大时，我在历史课上学到了改变历史的伟大革命：1776 年的美国革命、法国大革命、苏联革命等等。

这些故事让人觉得领导者发动了一场暴力革命，世界几乎一夜之间就改变了。

然而，当你深入了解许多这些事件的实际情况时，那种“暴力一夜革命”实际上只是重新建立了一个与之前类似（或更糟）的政府， 而真正的积极变化是通过较长时间的缓慢演变实现的。

我喜欢用的比喻是海上转向一艘船。

大型船只转向的速度有一定限制，超过这个速度船体可能会断裂。

船越大，转向速度就越慢。

公司或团队也类似，规模越大，从一个方向安全转向另一个方向的速度就越慢。

需要说明的是，我并不是说变革必须耗时很久，但它们也不会像挥动魔法棒那样一夜之间发生。

Source

在改善开发者体验时，你必须应对的一个主要因素是我们称之为“变更抗拒”的现象。

你对系统所做的任何变更，在推出时都会收到某些人的负面反馈。

这并不是因为变更本身有问题，而是因为用户习惯了之前的使用方式，他们不喜欢这种变化。

他们可能会批评新的用户界面，或者提出一些情绪化的理由说新东西“很糟糕”，但实际上他们往往只是因为发生了任何变更而感到不满。

这并不罕见；这是几乎所有人类都会存在的一个因素。

人们对在一定时间内愿意接受多少变更有一定的容忍度，超过这个限度，他们就会感到不安。

重要的是要识别出人们的反馈是单纯的变更抗拒，还是关于某些有价值内容的真实反馈。

有几种方法可以判断：

• 变更抗拒通常持续 3 到 10 天。

  如果你在推出变更后的前 3 到 10 天内收到用户反馈，并且大量用户没有提供相同的反馈，那么值得考虑该用户的反应是否只是变更抗拒。

• 对变更的抵触反馈通常带有情绪色彩。

  它可能是侮辱性的。

  它可能仅仅表现为一种观点（“新菜单的颜色很难看”），而不是事实（“我运行了新的命令行工具，它比旧的命令行工具慢了 10 倍。”）。

在管理变更时，你要避免的是制造过多的变更抵触情绪，以至于引发反抗。

反抗基本上表现为许多人愤怒到去找你的管理层，阻止你的工作。

遇到不确定时，推出较小的变更，针对较少的人群，扩展速度较慢。

随着时间推移，你会学会能够推出多少变更，以及多快推出。

绝不要进行“轰炸式”发布，让所有用户一次性经历大规模变更。

Source

最小干扰意味着：不要破坏用户的系统。

不要要求用户手动操作来适应变更。

必要时提供清晰的文档。

确保系统提供非常明确的错误信息，让开发者在首次尝试时如果失败，知道该怎么做。

基本上，要站在用户的角度思考，“我有很多事情要做，每天使用 30 个工具。我希望在有新功能或新工具时，获得怎样的体验？”

Source

唯一能让你获得 100% 采用率的方法是让你的工具使用起来无需任何步骤。

[…]

如果使用只需一步，可能会达到 80% 的采用率。

如果需要两步，能达到 30% 就算幸运了。

如果开发者需要阅读一份冗长的文档并遵循一套复杂的指令，那么你现在就知道为什么没人愿意使用你的东西了。

你绝不应该一开始就让一个工具达到零步骤使用的要求。

要做到这一点需要大量工作，而且在工具生命周期的早期阶段并不值得。

工具生命周期的早期阶段，工具使用起来稍微困难一些是可以接受的。

毕竟你只是把它交给小范围的热情用户群体进行初步反馈。

你应该专注于把工具做对，而不是一开始就让它融入人们的日常生活。

但一旦你把它做对了，“零步骤”将成为推动你实现 100% 采用率的座右铭。

Source

开发工具或改进开发者体验的全部意义在于，你投入创建和维护工具的努力应该比团队或公司节省的努力少。

[…]

现在，请记住，在软件开发中， 减少维护的工作量比减少创建的工作量更为重要。

因此，你不仅要考虑工具的即时影响（以及构建它的即时成本），还要考虑它随着时间节省的工作量（以及维护该工具随时间产生的成本）。

不同公司在进行此类计算时有不同的“时间视野” ⸺ 也就是说，如果我现在投入 X 小时，那么在 Z 年内公司总共节省 Y 小时的工作量。

Z 就是“时间视野” ⸺ 公司愿意展望多远的节省期。

在 Google，我们通常将这个时间视野设定为两年，因此任何对开发者生产力的投资都必须在两年内“收回成本”。

Source

这一领域最常见的错误之一是通过某些优化节省机器时间（CPU 使用、内存使用和磁盘空间随时间的成本），却忽视了节省了多少人力时间。

在大多数情况下，一小时的人力成本远远高于所有机器时间成本的数百倍。

在谷歌，我写过的一份非常受欢迎的文档基本上证明了这一原则，显示你必须节省数万小时的机器时间，才值得花费你自己几小时的工作。

虽然有很多合理的理由去优化机器时间，但改善开发者体验很少是其中之一。

当你考虑开发者生产力提升的成本和价值时，首先要考虑你将节省多少人力时间。

Source

平衡这一点的是，基于一天中的小时数、设计良好解决方案所需的时间、解决问题的人员数量、解决方案实际可以分配给多少工程师来完成等因素，人类在开发者体验方面能完成的工作量是有限的。

因此，当团队收到请求时，必须有一种方式来提供三种回答之一：

• “是的，我们现在就做”
• “我们以后会做”
• “抱歉，我们不会做”。

你可以将它们简写为“是”、“不是现在”和“否”。

Source

如果一个团队做了某件事给另一个团队带来了困难（“痛苦”），而制造困难的团队自己却从未因此经历任何困难，那么痛苦的程度只会不断增加。

这并不是说团队有恶意。

没有人想伤害同事。

这关乎自然的激励机制以及人类对这些激励的反应。

假设你有一个团队负责维护一个被其他十个团队使用的库。

这个库团队有自己的目标、自己的截止日期和优先事项。

他们专注于完成这些任务。

如果他们每天都被允许向客户发布破坏性更改，并且自己不会因此承担任何后果，那么他们每天都会发布破坏性更改，因为这是实现他们目标最有效和高效的方式。

库团队中可能有人觉得他们不应该这样做，但随着时间推移，业务压力无论如何都会迫使他们这样做。

团队可能会经历不同形式的“后果”，这些后果的效果有高有低。

最重要的是他们体验这些后果的速度，以及他们所经历的困难程度与他们转嫁给客户的困难程度相比如何。

令人惊讶的是，在这种情况下，人为的后果，比如糟糕的绩效评估或团队成员被别人责备，效果最差。

因为这些后果发生得太晚，远远晚于问题产生的时间，而且它们并没有改变导致团队行为的现实激励。

它们只是让团队感到被压迫 ⸺ 他们做了必须做的事，却因此被责骂。

这就是不公。

Source

解决问题的正确方法是改变谁来承担工作，这会改变激励机制和团队的基本“物理定律”。

我发现最有效的规则是：

如果一个团队想要做出改变，他们有责任代表公司执行该改变。

如果你是一个库团队，想要做出破坏性更改，你必须重构所有客户的代码库以采用新的破坏性更改。

如果你是一个网络安全团队，想要在公司所有代码库中实施新的控制措施，你必须亲自安装这些控制措施并确保它们正常工作。

这需要大量的工具支持才能实现。

你必须能够使用集中化的工具在整个公司范围内进行大规模的变更。

你必须有某种集中化的方式来知道在推出某些变更时是否会影响到他人。

你必须能够了解每一个依赖你某个库或系统的消费者，这样你才知道需要在哪里进行变更。

这里有很多工作要做。

但它会极大地改变公司的文化、基础设施团队（包括开发者体验团队）的效率，以及公司整体的工作能力。

它将基础设施团队从工作创造者转变为杠杆提供者，减少公司采用变更所需的总努力量，并显著提高整个业务中有益变更的速度。

Source

这不是我以前所知道的宁静。

它是一股平静的潮流，是一种存在感多于缺失感的状态。

我所看到、触摸或听到的一切都充满了奇妙的秩序感。

我拥有一颗空无的心，一颗漂浮的心。

我极度专注于当下，几乎没有对过去或未来的意识或兴趣。

我的整个环境感觉相互连接，就像一个庞大而有呼吸的有机体中的细胞。

体验这种宁静就是成为它。

Source

在那个时候，我对自己的脑损伤几乎一无所知。

我没有任何疼痛感，所以我对新状况的思考是模糊且短暂的。

我的思绪没有被为什么我住院以及发生了什么事的问题占据，而是沉浸在完全不同的感知中。

最微小的活动都会让我着迷。

给自己穿衣服时，我被布料与皮肤之间的距离所震撼。

刷牙时，我被刷毛的硬度和牙龈的柔软所吸引。

我还花了大量时间望向窗外。

我的视线主要是医院屋顶，那些灰色且无纹理的面板，尽管如此，我对附近的一棵树产生了浓厚的兴趣。

我只能看到树枝的顶部，但我会专注地观察这部分针叶和树枝，着迷于微风如何完全改变它们的形状。

那棵树既永远存在，又永远不同。

Source

我翻开了那本书。

那是Agatha Christie的一部小说，可能是我多年前读过的。

我翻到第一章，缓慢而均匀地翻阅前几页，这个动作似乎对我来说很自然。

但到了第三页，我停了下来。

我回到第一页，重新开始。

这次更慢，慢得多。

我的眼睛在明亮的阳光下聚焦又重新聚焦，但我依然只能看到那些曾经是文字的黑色、阻塞的形状。

现在回想起来，我不知道自己怎么会如此确定那是一本Agatha Christie的小说，尤其是在那一刻我意识到自己已经无法阅读了。

手中这本既熟悉又陌生的书，我首先感受到的是语言的真正丧失。

在我的一生中，语言一直是每一次个人或职业成就的核心，很少有事情能带给我如此多的快乐和意义。

如果有人曾警告我，可能会被剥夺阅读能力，即使只是暂时的，那将是难以承受的巨大打击。

或者我曾这么想过。

但有一天，我真的无法阅读眼前的书，段落看起来不过是一堆无意义的杂乱，而我对这巨大损失的实际反应却出奇地平静。

毫无疑问，意识到失败令人震惊，但有痛苦或焦虑吗？

没有。

我的反应远没有那么强烈。

一种模糊的失望感掠过我，但随后……我无法以这种方式使用语言，只觉得这不过是暂时的信息。

既然这种能力消失了，我再也无法思考它应该如何或为何会对我的生活产生任何影响。

回想起那一刻令人震惊，想到失去如此重要的东西时，我竟然只感受到一丝模糊的情绪。

但我当时活在当下——沉浸在宁静的安慰中——无法完全意识到我的身份感已经发生了变化。

直到几周后，我才察觉到自己失去了多少，以及我必须多么努力才能找回它。

然而，拿着那本书时的不适感在我合上书的瞬间就消散了。

毫不费力地，我的注意力又回到了那片不可能的蓝天上。

Source

我的失语症也有看不见的影响，以许多人甚至不会想到的方式。

受影响的不仅仅是我的外在语言。

我的内心独白，我自我引导的言语，也几乎完全沉默了。

取而代之的是那灿烂的宁静。

滋养的宁静。

启迪的宁静。

Source

我多少能模糊地理解别人对我说的话。

我并不难以集中注意力：只是那些词，无论是单独还是组合在一起，都没有意义，更令人惊讶的是，我对此几乎毫不在意。

我甚至失去了进行自我对话的能力。

我只是存在着。

仿佛没有了语言，我就无法关心明天。

Source

左半球的“粘性”，即倾向于反复使用它熟悉的东西，往往会强化它已经在做的事情。

这个过程具有反身性，就像被困在一面镜子的迷宫中：它只会发现更多它已经知道的东西，也只会做更多它已经在做的事情。

相比之下，右半球看到的是更全面的画面，采取的是更广阔的视角。

Source

然而，动脉瘤破裂后我当然还能思考。

在许多方面，我的思维从未如此清晰。

我保留了复杂思考的能力，但这些思考并不是通过词语或短语来表达的，我的想法也不像以前那样相互聚集或激活。

这不是无知，而是一种纯真。

总体来说，这种沉默对我非常有利。

由于我的内心独白被静音，我在早期基本上避免了理解自己的状况。

无法问自己：我怎么了？

我既不能，也没有列出许多存在的问题。

我不再是自己生活的叙述者。

Source

十年后，经历了另一场重大手术和无数小时的正规与非正规语言治疗，我已经恢复了大部分语言能力。

究竟有多少永远失去了，我永远不会知道。

我不能保证自己和五年前、十五年前的人有多相似，也不能保证五十秒后的自己还是同一个人。

但我知道，这样的经历并不限于脑部受伤的人。

每当我们谈论童年或生命中任何遥远的时期时，我们都必须容纳多个版本的自己——尽管我们不再像那些人那样发声、说话，甚至思考。

我的变化比许多人更迅速。

但我们每个人都包含着这样的多重自我。

我们很少为生活中的下一阶段做好准备，常常跌跌撞撞地进入自己并不具备所需专业知识的位置。

考虑到这一点，完美永远不可能成为目标，但流动性或许可以。

有时，在不自觉中，在做我们正在做的事情的过程中，我们成为了能够胜任这些事情的人。

语言既是我的伤害，也是治疗这种伤害的方法，在很多方面，我一直在通过写作找回流利的表达。

我怀疑即使语言不尽如人意，我也会继续努力去触及它。

言语，无论是公开的还是内心的，都可以是一种礼物，但有时它在完全不被使用时反而是最美好的。

一个词可以多么美丽。

几乎和它之前的寂静一样美丽。

Source

这个概念听起来很简单：阅读文档并编写一些 .mdc 文件。

但说实话，许多开发者虽然理解其好处，却因为创建规则感觉像额外的工作而犹豫不决。

这增加了摩擦。

这是我自己和向朋友解释时都注意到的：我们都理解这个概念，都看到长期的好处，但很少去实施。

即使我知道光标规则从长远来看能节省时间，我也常常不去创建，因为编写它感觉像一道障碍。

那么你如何克服这种阻力呢？

你建立一个系统来构建系统本身。

我知道这听起来很元 (meta)，但这正是我们需要的：用 AI 来为自己编写规则。

怎么做？

通过创建一个元光标规则 (meta cursor rule)。

这意味着创建一个规则，作为编写所有其他规则的模板。

它定义了所有规则应遵循的结构和内容。

一旦你有了这个元规则，过程就变得简单了：

1. 注意你想要规范的模式。
2. 打开 Cursor 聊天。
3. 指引 AI 使用你的元规则（例如，“使用 cursor-rule-creation.mdc 指南……”）。
4. 让它根据你的对话写一条新规则（例如，“根据这次聊天为我们的组件结构写一条规则”）。

实际上，我个人在两种常见场景中使用这个方法：

• 在长时间编码会话中

  经过数小时与 AI 一起研究特定模式或约定后，我会意识到，“下次我不想再解释这个了。”

  我只需告诉 AI：“基于我们迄今为止讨论的所有内容，并遵循元光标规则模式，请为这种方法创建一条规则并适当命名。”

  AI 会起草规则，我保存以备将来使用。

• 当我有具体想法时

  有时我已经确切知道想要规范的模式。

  我会打开聊天，简要描述我的意图，指向元光标规则，并请求 AI 编写一条针对性的规则。

  这就像是将我的想法直接口述成结构化文档。

这种方法大大减少了构建规则库所需的工作量。

AI 会按照你的模板生成结构良好的草稿，你可以快速保存并使用。

"A great product isn't just a collection of features. It's how it all works together."

“一个伟大的产品不仅仅是功能的集合，而是所有功能如何协同工作。”

⸺ Tim Cook, September, 2014

"We say no to a lot of things so we can invest an incredible amount of care on [what we do]."

“我们对很多事情说不，以便能在我们所做的事情上投入极大的关怀。”

⸺ Jonathan Ive, July, 2012

"The design is done when the problem goes away."

“当问题消失时，设计就完成了。”

⸺ Jason Fried, 2012

"Good design is obvious. Great design is transparent."

“好的设计是显而易见的。伟大的设计是透明的。”

⸺ Joe Sparano, 2009

"You can't just ask customers what they want and then try to give that to them. By the time you get it built, they'll want something new."

“你不能只是问客户他们想要什么，然后试图给他们。等你做出来的时候，他们会想要新的东西。”

⸺ Steve Jobs, 2005

"Simplicity is not the goal. It is the by-product of a good idea and modest expectations."

“简洁不是目标。它是一个好主意和适度期望的副产品。”

⸺ Paul Rand, 1997

"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong."

“当我在解决一个问题时，我从不考虑美感。我只考虑如何解决问题。但当我完成后，如果解决方案不美观，我就知道它是错误的。”

⸺ Richard Buckminster Fuller, 1980

"The design of good houses requires an understanding of both the construction materials and the behavior of real humans."

"要设计出好房子，就必须了解建筑材料和真实人类的行为"。

⸺ Peter Morville, 2002

如何开始学习？

1. 玩一玩某样东西。
2. 阅读相关文档。
3. 再玩一玩。
4. 再读文档。
5. 再玩一玩。
6. 再读文档。
7. 再玩一玩。
8. 再读文档。
9. 明白了吗？

这个想法是你的大脑在一次学习中只能接受有限的“新数据”。

玩弄某样东西不会引入太多新数据，但它会将你脑中的数据从“新”类别转变为“熟悉”类别。

阅读文档不会让任何东西变得“熟悉”，但它会补充你的“新”数据槽。

大多数人即使最初阅读了文档，也很少再回头看。

他们达到某个最低熟练度后就不再学习更多。

但现代操作系统、语言、网络，甚至应用程序，绝不可能在一次学习中掌握。

你必须多次经历这个两步学习循环才能精通它。

进度与功能与质量

现在谈几句项目管理的话。

迟早，几乎任何项目都会面临进度、功能和质量之间的权衡。

想象一个学生在最后一晚写学期论文。

他有三个令人不快的选择：

• 他可以迟交（错过进度）；
• 他可以交一篇内容不全的短论文（减少功能）；
• 或者他可以胡乱凑数（降低质量）。

类似地，在软件项目中，人们常常需要在按时发布、减少功能，或按时交付所有功能并希望它能正常工作之间做出选择（通常不会正常工作）。

关于这个决定，最重要的是要意识到这确实是一个决定。

不能指望奇迹发生来逃避它。

如果你不自觉地做出反应，那么外部环境将驱动这个决定。

好的，假设你面临权衡，选择了进度延迟。

不要选择小幅度的延迟……选择一个大而显著的延迟。

如果你说“我只修复这个问题，尽快完成”，那么很可能你以后会希望当初多花一点时间。

如果你说“我觉得我需要多一天，所以我会延迟一周”，那么更有可能的是你在一周结束时的成果能满足需求。

一次性大幅度延迟比反复每天或每小时延迟要好得多。

如果你选择放弃功能，同样，要大刀阔斧地削减。

不要胆怯，也不要假装“如果有一点空闲时间，我会做这项工作”。

你项目中的那个功能已经不复存在了，要充分利用减少的需求带来的所有节省！

我无法提供太多关于如何降低质量的建议，因为那总是我在项目中最后才考虑放弃的选项。

睡眠

简单而显而易见，但确实如此……工程需要一个警觉的头脑。

投入大量连续的时间来解决一个问题是非常容易且诱人的。

人们可能进入一种“心流”状态，思维完全沉浸在问题中，工作就这样一小时接一小时地流淌出来。

许多作家报告说，他们观看故事的发生，然后只是转录他们所看到的内容，一页又一页地敲打出文本。

许多软件工程师也有过类似的感觉，代码似乎在他们看着自己敲打时自发地出现。

我相信大多数真正的工作都是在这种状态下完成的。

然而，我的经验是，“心流”状态可能会悄然且逐渐地结束。

在没有察觉到任何变化的情况下，我注意到新的工作不再从我手中流出，我花了大量时间修正几分钟前刚犯的错误。

脑海中不再有自信闪现的想法，取而代之的是疑虑和问题浮现。

此时，很容易产生多花几个小时解决问题的冲动。

“我已经在这里了，而且刚才效率很高，为什么不熬夜直到解决问题呢？”这是个陷阱！不要这样做！

相反，我建议：回家，吃饭，洗澡，睡觉，让自己重新振作。

第二天继续工作。

当你睡觉时，你的大脑仍会在处理问题，你很可能醒来时会有新的想法。

第二天上午 10 点到下午 2 点之间，你的效率会比从午夜到上午 10 点熬夜时更高。

这种策略有一个问题：早晨重新激励自己。

如果项目是你自己选择的，通常不会有问题。

如果是你必须做但不喜欢的事情，你必须在重新激励自己和缺乏睡眠导致的极低生产力之间找到平衡。

我也非常有意识地决定从现在开始不再玩任何 roguelike 游戏。

我想明确说明，这并不是因为我认为这样会做出更好的游戏，而是因为制作游戏是我的爱好，发布游戏并从中赚钱不是，所以天真地探索 roguelike 设计（尤其是 deckbuilder 设计，因为我以前从未玩过这类游戏）对我来说是一种乐趣。

我想犯错误，我想重新发明轮子，我不想借用现有游戏中经过验证的设计。

那样可能会做出更紧凑的游戏，但会违背我热爱制作游戏的初衷。

Source

我做游戏大约有 10 年了，做视觉艺术项目更久，而我为创意业余项目养成的一个非常重要的习惯是，当我不再有动力时就停止工作。

这有两个主要原因；首先，它让我能够在不完全耗尽对上一个项目的热情的情况下转向下一个想法。

其次，更重要的是，在这种情况下，它让我能够无罪恶感地休息一段时间，并可能以后带着积极的情绪回到项目中。

Source

我的心脏真的让我很困扰。

我经常要熬到日出才能入睡，精神状态也非常糟糕。

我喜欢开发这款游戏，但长时间如此公开且高强度地工作，真的让我感到疲惫不堪。

有一晚，我和伴侣一起看电影《深渊》，突然我出现了隧道视野，心跳剧烈，我感觉有严重的不对劲。

我坐在沙发上好一会儿，完全惊慌失措。

我真的很害怕。

我给医生打电话，第二天早上去看了他。

他向我保证这不是心脏病发作或心力衰竭，而是焦虑发作。

我平时并不焦虑，过去也没有这方面的问题，但我想长时间的强烈压力确实造成了不少伤害。

Source

那天让我印象深刻的另一个时刻是当天晚些时候，当我的伴侣下班回家时。

她整天都在关注着，努力工作却难以集中精力，回家时给了我一个大大的拥抱。

我当时都不确定自己能否挺过发布，但我们做到了。

没有她，我无法完成这一切。

我们点了汉堡当晚餐，开了一瓶香槟庆祝。

Source