how your email finds me (if youre waiting for a decision or reply pls dont take it personally im just in peak crunch mode for aie)
这就是你的邮件通常会在什么状态下被我看到（如果你在等一个决定或回复，pls 不要往心里去，我只是正处在 aie 的高压赶工期）
## The Future Codebase After the PR dies, after the Code Review dies, i am seriously wondering if Git needs to die next. roughly 20-40% of code spend is just managing and updating merge conflicts. necessary evil? or legacy "horseless carriage"? cargo culting the past? we don't do line by line merge conflicts when we collaborate with human colleagues - instead we chat, suggest edits, do side comments, and an owner ships it. btw we also don't do CI/CD even collaborating on documents with serious legal/financial implications. maybe the future codebase looks more like a Notion or Linear database than .git objects. It will be less efficient, but more scalable. exactly the Salty Lesson.
## 未来的代码库 在 PR 消亡之后，在 Code Review 消亡之后，我很认真地在想，接下来是不是连 Git 也该消亡。大约 20–40% 的代码投入，只是花在管理和更新 merge conflict（合并冲突）上。这是必要之恶？还是一种遗留的“horseless carriage（无马马车）”？是在对过去进行 cargo cult（货物崇拜）式模仿吗？我们和人类同事协作时，并不会按行处理 merge conflict——相反，我们会聊天、提出修改建议、写侧边评论，然后由某个 owner（负责人）来发布。顺便说一句，即使是在协作处理具有重大法律/财务影响的文档时，我们也不会用 CI/CD。也许未来的代码库，看起来会更像 Notion 或 Linear 的数据库，而不是 .git objects。它的效率会更低，但可扩展性会更强。完全就是 The Salty Lesson。
neat thing about developer exception engineering is: the happy paths are all happy in their own way. the unhappy paths are ~universally the same.
developer exception engineering 的一个妙处在于：happy path（正常路径）各有各的顺法；而 unhappy path（异常路径）却几乎到处都一样。