“知道如何”的诅咒，或者；修复一切的困境
“知道如何”的诅咒，或者；修复一切的困境
April 24, 2025 9 min read Source 目录 Technical Capability as a Moral Weight One Must Imagine Sisyphus Happy Entropy Is Undefeated The Illusion of Finality Technical Work as Emotional Regulation The Burnout You Don’t See Coming Learning to Let Go A New Kind of Skill Footnotes
一切都始于无意之中。
你用一个十行的 Python 脚本重命名一批文件，或者你为常用的 git 命令创建别名，以减少两次击键。也许你构建了一个小的 shell 函数来格式化剪贴板中的 JSON。
你甚至不是想变得聪明。你只是在解决一些小问题。让机器做它本来就应该做的事情。然后，某些事情发生了。你跨越了一个_阈值_。你看着你的工具、你的环境、你的操作系统——甚至你的编辑器——突然间，一切都成为了目标。
你_可以_重建它（如果你想的话）。你_可以_改进它（如果你想的话）。
然后有人挑战你。也许是开玩笑，也许带着一丝希望。然后房间里的气氛就变了。
它突然变成了别的东西。它变成了：
你_应该_。
从那一刻起，世界以新的、具体的方式破碎，只有_你_才能看到。
Technical Capability as a Moral Weight
在我学会编程之前，有问题的软件令人沮丧但可以忽略。多年来，我只是像消费者一样“使用”计算机。我就是那些公司试图哄骗购买他们的产品或订阅他们的服务的对象。而不是他们更喜欢在软件版本中避免的技术怪才，或者因为操作系统而被禁止玩游戏的人。
现在它变得_挑衅_了。我可以看见我希望我看不见的模式，找到我可以归因于对某个概念的理解（或缺乏理解）的疏忽，并且我可以_听到_那个编造我必须调试的程序的电脑文盲脑海中回响的声音。
我像一个好外科医生注意到跛行一样注意到缺陷。这个网站到底为什么为静态页面发送 10 MB 的 JavaScript？为什么 CLI 输出不能被 awk 解析？为什么这个配置是硬编码的，而它可以是声明式的？
这些不仅仅是问题，它们是_指责_。而且，不幸的是，它们不会停止。
既然我已经学会了注意到，我对软件的看法已经完全改变。
每一段软件都变成了一个 TODO 列表。每个系统都变成了更好的系统的脚手架。每一个不便都变成了对不作为的控诉。
One Must Imagine Sisyphus Happy
就像加缪的西西弗斯一样，我们注定要将我们自己的系统的巨石推上山——一次修复，一次重构，一次脚本。但与西西弗斯的故事不同，诅咒不是由某个神灵施加给你的。我们自己建造了巨石。而且我们在向上爬的时候一直在打磨它。
我已经数不清我启动了多少个以“是的，我可以做得_更好_”的不同版本开始的项目。
- 一个静态网站生成器，因为现有的生成器有太多的意见。
- 一个笔记工具，因为我不喜欢其他人构建元数据的方式。
- 一个 CLI 任务运行器，因为 Make 很隐晦，而 Taskfile 是 YAML 地狱。
- 一个用 Rust 编写的个人 wiki 引擎，然后在 Go 中，然后在 Nim 中，然后再回到 Markdown。
- 一个家庭实验室仪表板，因为我不喜欢 webslop。
这个列表还在继续，相信我，它_确实_在继续。我的开发目录目前已接近 30 GB。
如果你问我，我是在解决真实、无辜的问题。但事后看来，我也在喂养其他东西：一种控制欲。我构建的每一个新工具都是一个我_拥有_的沙箱：没有奇怪的错误。没有遗留的限制。没有我完全不同意的决定。直到，当然，我变成了遗产。
卡夫卡曾经写道“笼子去寻找一只鸟”。1 这就是这些项目可能变成的样子。我们不断构建的空系统，等待目标、等待清晰、等待……救赎？我不确定你还会怎么称呼这种追求。
Entropy Is Undefeated
现在让我们回去。回到我们还不懂事的时候。
软件不会一直保持“已解决”的状态。你编写的每一个解决方案从它存在的那一刻起就开始腐烂。不是现在，不是稍后，但最终会。库会弃用。API 会更改。性能会逐渐下降。你曾经完美的工具会因为 libfoo.so 现在是 libfoo.so.2 而悄无声息地崩溃。2
我_确实_有过脚本因为网站更改了其 HTML 布局而悄无声息地失败的情况。我_确实_有过配置格式因为上游版本升级而中断的情况。我_确实_有过 Docker 容器因为 Alpine Linux 轮换了镜像 URL 而死亡的情况。
在每一种情况下，直接的情绪反应不仅仅是不便，而是更像_内疚_。我构建了这个，而且我确实知道得更多。我怎么可能没有预见到这一点？是时候修复它了。
如果你随着时间的推移更换了系统的每一个部分，它还是同一个工具吗？它仍然服务于相同的目的吗？_你_呢？
The Illusion of Finality
我认为我们是在自欺欺人。
“如果我把这个设置弄对了，我就再也不用碰它了。”“如果我只写这一个工具，我的工作流程就会是无缝的。”“如果我自动化了这个，我将永远节省时间。”3 “一次编写，到处运行。”放屁。
我承认，这是一个诱人的谎言。它将编程描绘成一种征服。一系列你赢得的战斗，或者你完成的挑战。但想象中的战争永远不会结束。你不是在建造一座城堡。你是在挖掘战壕。而且每次下雨都会被淹没。这些考验永远不会完成。
Technical Work as Emotional Regulation
在用文学引用填满这篇文章的主题上，让我引用斯多葛派的马库斯·奥勒留。
你对你的思想有力量——而不是外部事件。意识到这一点，你就会找到力量。
但编程引诱我们相信我们_可以_控制外部事件。这就是痛苦开始的地方。这里发生了一些更深层次的事情。这_不仅仅_是关于软件。
我相信有时候构建东西是我们自我安慰的方式。我们编写一个新的工具或脚本，因为我们迫切需要一场小小的胜利。我们编写一个新的工具，因为我们不知所措。重构它，不是因为代码很乱，而是因为你的生活很乱。我们追逐完美的系统，因为它给了我们在其他一切都在旋转时可以抓住的东西。这是我从使用 NixOS 中学到的教训。
我写了整个应用程序，只是为了避免思考我为什么不快乐。编程给你即时反馈。你运行它，它就工作了。或者它_不_工作，你修复它。无论哪种方式，你都在_做一些事情_。
这种能动性是令人上瘾的。尤其是当生活的其他部分没有提供它的时候。我们编程是因为我们_可以_，即使我们不应该。因为至少它给了我们一些可以反抗的东西。
The Burnout You Don’t See Coming
倦怠不仅仅来自过度工作。它来自_过度负责_。
而编程，一旦足够深入地内化，就会让一切都感觉像是你的责任。臃肿的网站。效率低下的脚本。你工作时笨拙的入职流程。你_可以_修复它。那你为什么不呢？
你非常清楚的真相是你无法修复所有的事情。你_知道_这一点，无论你的技能水平如何，你一直都知道这一点。但试着告诉你的大脑中将每一次低效率都视为一种道德失败的那部分。
尼采警告说不要凝视深渊太久。但他并没有警告说，当深渊是一个 Makefile 或一个 3 万行代码的 Typescript 项目时会发生什么。
Learning to Let Go
那么出口在哪里？这是否类似于萨特的关于地狱的描述，地狱_是_其他人以及他们如何与你的软件互动？或者这是一个奇怪的倒退的地狱，人们创造了你必须与之互动的软件？
第一步是认识到_不是所有坏掉的东西都属于你修复_。不是每个工具都需要更换。不是每一次糟糕的经历都是行动的号召。
有时候，仅仅_使用_这个东西是可以的。有时候，知道它_为什么_坏掉就足够了——即使你不修复它。有时候，你能做的最有纪律的事情就是_离开_你懂得解决的问题。这其中有一种力量。
不是冷漠，不是。也不是懒惰。只是……一些克制。
A New Kind of Skill
如果真正的技能不是技术掌握呢？或者更好的是，如果它是情感清晰度呢？
- 知道哪些问题值得你付出精力。
- 知道哪些项目值得维护。
- 知道你什么时候是在帮助别人而构建——什么时候是在为了应对而构建。
- 知道什么时候停止。
这就是我现在正在努力学习的东西。在兴奋之后。在痴迷之后。在倦怠之后。我试图让事情保持一点点的破碎。因为我已经意识到我不想_修复所有的事情_。我只是想在一个经常不正常的世界里感觉良好。我可以修复一些东西，但不是所有东西。
你学会了如何编程。你学会了如何修复东西。但你将学到的最难的事情是什么时候_让它们保持破碎_。
也许那是所有人性中最重要的技能。
Footnotes
Back to all posts
GitHub Twitter RSS Feed
This site is part of the Nix webring. Click the logo to visit a random site.
Git Branch development
© 2024-2025 NotAShelf