Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Dave Plummer:编程、自闭症与老派微软往事 (2025-09-06, glm-4.7-flash)

导读

Dave Plummer 既不是那种在科技博主圈子里制造话题的喧嚣人物,也不是那种意识形态鲜明的产品布道者。他更像是操作系统深处的幽灵——当Windows崩溃时,你不会看到他,但你会肤浅地感谢Windows感叹号旁边那个简陋却坚挺的进程管理器。他把Windows著名的Zippo压缩支持和《太空侵略者》给微软化了,却在光鲜亮丽的PPT和战略发布会上消失无踪。

这期对话之所以值得深夜细读,不仅是因为它揭露了微软“黄金时代”那种令现代独角兽都窒息的集体智力密度,更因为它提供了一个极为稀缺且充满张力的视角:在业界的“抽象”和“黑箱”叙事中,一个人如何通过极端的“低层聚焦”与“物理约束”来对抗熵增。当全行业都在拥抱第一层抽象(AI)、第二层抽象(云)和第三层抽象(SaaS)时,Dave 提醒我们,代码的执行效率本质上是由对原始硬件与底层逻辑的不可动摇的控制力决定的。这不仅是对程序员脑力的辩护,更是对一种正在消逝的“系统建筑学”的挽歌。

核心观点

Dave Plummer 的核心世界观可以概括为:通过极致的物理约束与“单线程”式的心智聚焦,在混乱的复杂系统中构建出不可替代的高性能基石。 这一观点不仅挑战了“现代工程通过增加抽象层级来简化复杂性”的主流叙事,也侧面印证了某种性格特质——正如他自称的“自闭症特质”——实际上是人类历史上解决最硬核技术问题的关键杠杆。

以下是其四个关键判断:

1. 性能的护城河在于对底层机制的掌控

Dave 坚信,编程能力的上限不在于驾驭多复杂的框架,而在于对原始计算指令的掌控力。他在探讨 Windows NT 早期开发时提到,当时他们不仅仅是在写代码,而是在与硬件极限做斗争。例如,他深入解释了 A20 线和 640K 内存限制背后的技术逻辑,并毫不避讳地花费巨大精力去解决内存不对齐导致的极低性能问题(MIPS 架构下的异常处理开销)。他认为,Microsoft 后来在 NT 上的成功,部分归功于 Dave Cutler 带来的那种像农民一样“盯着每一个字节是否合乎标准”的严苛工程文化。

逻辑链条: 深入理解硬件层面 $\rightarrow$ 解决物理层面的“脏活脏累” $\rightarrow$ 这种执念曾是 Windows 早期工具超越竞品的根本原因。

2. 资源极度受限是优秀的催化剂

这听起来像是老生常谈的“KISS原则”,但在 Dave 的故事里,这几乎是一种迷信。他亲手打造的 Windows Task Manager 的传奇之处不在于它添加了多少华丽的功能,恰恰相反,在于它版本初期的 87KB。为了实现这一点,他拒绝了连接 C 运行时库(C Runtime),手动管理所有对象构造,甚至自创了一种类汉明码的算法来只更新界面中发生变化的单元格,从而实现了极其流畅的 UI 渲染。这直接反驳了现代软件开发“先实现功能,再优化性能”的流弊,证明了在极端约束下诞生的代码,其健壮性和效率是后来者只能仰望的。

逻辑链条: 野心的缩减(只保留必要的核心功能) $\rightarrow$ 遭遇物理约束(没有 C Runtime,内存极低) $\rightarrow$ 迫使发明定制化、极简的原生方案 $\rightarrow$ 最终交付的产品在数十年后仍具统治力。

3. “调试”是程序员的真容,也是思维模式的外化

Dave 提到他职业生涯中有 80% 的时间是在 Debug。他不仅将这种活动视为工作,更将其内化为一种心理特质——即 “自闭症思维”中的 Monotropism(单向聚焦模型)。对他而言,发现一个 Bug 就像是在黑盒中寻找丢失的钥匙,那种纯粹的逻辑排查过程本身就是奖赏。这种通过排除法、 asserts 断言和极端细节审计(甚至把电话号码写在断言里)来解决问题的习惯,是他对“软件质量”的定义。这种人认为,如果代码在崩溃证明它错了之前,都被视为已经“正确”,那么生产环境就会充满隐患。

逻辑链条: 对细节的强迫症 $\rightarrow$ 将 Debug 视为一种愉悦的探索过程而非麻烦 $\rightarrow$ 开发出深信“断言优于警告”的工程哲学 $\rightarrow$ 避免了后来随 Windows 体积膨胀而来的不可维护性。

4. “奇怪”通向卓越,而平庸是安全的

Dave 的面试哲学极其冷酷:要展示你的具体产出(Portfolio),而不是让你的人格魅力说服对方。 他认为,试图通过幽默、性格或所谓的“软技能”去填补认知的鸿沟是高风险的,特别是对于处于光谱上的人来说。正是这种对他人的意图缺乏“读心术”的直白,反而让他跳过了很多职场政治和无效社交,把节省下来的脑力全部用于构建实际的产品(如早期的 HyperCache)。他是典型的“苦干者”而非“社交场上的弄潮儿”,这种特质的反面正是现代科技行业所诟病的“表演型”文化。

逻辑链条: 对抽象社交模式的失明/逃避 $\rightarrow$ 专注于可视化的、可量化的技能展示 $\rightarrow$ 在语言不通的环境下仍能无缝交付代码 $\rightarrow$ 将尴尬转化为单点突破的野心。

这些观点之间形成了紧密的张力:极致的物理掌控(观点1)与单纯的低配优化(观点2)在他身上是如何统一的?答案在于他的思维模型——只有深刻理解“脏活”(底层字节、汇编),才能在“净活”(C++、高级 API)中做出明智的取舍。而观点 4 的情商缺失,恰恰掩盖了他在观点 3 中展现出的惊人逻辑专注力。

批判与质疑

作为观察者,我们需要从外部视角审视这套基于“低层极客”的叙事体系,因为它带有明显的幸存者偏差和时代局限性。

首先,“深度钻研”是否总是划算? Dave 生动描述了他在 Windows 95 早期 Unicode 移植中,因为一条 ID List(标识符列表)在某些机器上位于奇数地址导致性能下降数千倍,但他盲信自己的直觉而输了争论(当时管理层要求兼容性通俗性胜过极端效率)。这证明了“过度优化”是存在的,且极其讨人嫌。在当今的云计算时代,服务器算力无限,这种在单个字节上较真的精力,若不能转化为巨大的商业价值,就是资源浪费。

其次,这种工程文化在“现代大规模协作”中还具有适应性吗? Dave 崇拜 Dave Cutler 的“农场主式”管理,要求每个提交都必须经得起“检查”。然而,现代软件工程的复杂性已经以指数级上升,Stack Overflow 早已取代个人直觉成为基础设施。如果一个团队里的每个人都是 Dave,都需要把代码维护几百年,那么技术债将会爆炸性失控。依赖极少数天才修补系统缝隙的做法,在微服务和高并发分布式系统中是行不通的,它需要的是通用的护栏和抽象规范,而不是个人英雄主义的坚守。

最后,他对“营销与用户体验”的判断过于书呆子气。 他提到自己因为认为默认打包光盘是“常识”而违规(违背“消极同意”付费原则),或者对软件售后推销的困惑。这些未必是能力问题,而是社会适应性的滞后。他没能意识到,在那个销售如同角斗场的环境里,如果不学会用“恐惧”或“色欲”来包装产品(如他将广告策略归结为恐惧/贪婪),即使产品再好,也会倒在起跑线上。他的某些软件公司失败,正是因为他宁愿遵守自己逻辑里的“绝对真理”,也不愿在商业规则的灰色地带妥协。

尽管存在这些局限,Dave 对复杂的透明化要求——尤其是对 Windows 系统应当对用户保持“非敌对”态度——值得今天的平台设计者深思。

行业视野

Dave Plummer 的这番对话,不仅是个人史,更是软件工程范式的一次回望。它标识出了一场从“以物理为中心”向“以人为中心”的剧烈偏移

在过去(以及 Dave 经历的微软黄金时代),操作系统是一个接近物理世界的实体,程序员和硬件直接对话,每一个字节、每一个时钟周期都关乎存亡。这造就了 Dave 这种对 6502 汇编、MIPS 寻址模式和 A20 线路如数家珍的工程师。而对话中提到的另一端——当他试图让 AI 替他编写 Python 代码时——“Vibe coding”的出现,标志着软件已经完全变成了第三层抽象。当程序员只需要“拉扯组件”时,我们对机器 working 的残忍真相反而越来越无知。这与 Dave 所怀念的“极具工匠精神的单点突破”形成了鲜明的时代断层。

此外,他的论点印证了编程语言演化中的“实验性复兴”趋势。在对话后半段,他痴迷于通过“GitHub Primes”项目实际测试不同语言的性能,并坚持 Zig 语言在特定场景下超越了 C++ 和 Rust。这并非技术民科行为,而是对现代语言编译器优化黑箱的不信任,试图通过真实的环境还原(100个核心并行计算质数筛)来寻找最底层的“实干语言”。这投射出行业对 Rust/Zig 等系统级语言的渴望——人们在寻找回归可靠性的同时,不牺牲太高的性能和抽象便利性。Dave 视觉化地演示了 “开源社区对抗闭源黑盒” 的力量:只要提交代码,Zig 就能战胜 C++,这是一种纯粹的技术自信。

启示与建议

这场对话强制性地重构了我们对“技能”和“成功”的假设:

  1. 硬技能(技能)重于软技能(人设): 在面对强工具和复杂系统时,具体的交付物(代码、作品集)永远比你的逻辑无法验证的“潜力”更有说服力。Dave 的建议对于所有处于弱势沟通地位的极客——无论是自闭症谱系还是内向者——都是一种赋能。
  2. 约束是设计的边界: 不要在“无限”的 feature 列表中迷失,而是要像 Task Manager 那样,通过极其严格的约束条件(时间、体积、功能集)来倒逼设计,往往能创造出灵魂级的作品。

针对不同读者的建议:

  • 架构师与 CTO: 不要迷信宏大的业务愿景,去关注那些被称为“垃圾代码”的底层修补工作。就像 Dr. Dave 因为解决了 C-DROM 缓存问题,才有了后来 Windows 的高性能体验一样。那种被称为“环境变量冲突”或“启动画面太丑”的琐碎问题,往往是系统稳定性的决定性短板。建议: 建立一种机制,奖励那些不仅能写新代码,还能在旧系统中“大动干戈”地瘦身和优化的工程师。
  • 自闭症/高功能阿斯伯格人群(及家长/伴侣): Self-Diagnosis is the most dangerous thing you can do, but it’s often the only way you can get help. 不要被“社会面具”要求你成为的那个圆滑的人同化。Dave 提供了极具参考价值的视角:你的“ Literalism(字面主义)”在处理逻辑闭环时是降维打击,你的“Monotropism(单向聚焦)”在 Debug 时是天赋。你需要做的不是改变你的大脑电路,而是学会把你的“硬技能”包装成可出售的产品,而不是试图让自己擅长那种靠氛围和猜测来赢的游戏。
  • 初级程序员: 像写 Shell 脚本一样学习 C 或汇编(哪怕是伪代码)。理解指针、内存管理和不存在垃圾回收的世界对你没有坏处,它能让你在快速用 Python/Node.js 完成原型后,有能力跨出一步,看懂代码背后真正的执行成本。

金句摘录

  1. “I realized that if you think you’re tricking me into not doing what I want to do, you’re probably right.”

    中文意译: “如果你感觉你在试图操控我不做我想做的事,那你可能确实是对的。” 语境: Dave 批评现代 Windows 界面设计(如“推荐设置”)过于激进,实际上是在对抗用户的无意识选择,这让用户感到被侵犯和控制,破坏了信任感。

  2. “I’m trying to preserve [the physics of Space Cadet Pinball], but what it is, is I had a bug where I will draw as many frames per second as I can… So you’re getting arguably better, or at least different physics.”

    中文意译: “我试图保留《太空旅伴》的物理特性,但结果是我写成了一个每秒渲染数千帧的 Bug……所以你得到的是某种可能更好但也确实不同的物理效果。” 语境: 讲述他在移植 Pinball 游戏时,追求极致渲染帧率导致破坏了原有的物理常数,讽刺了“因为能快所以快”的技术惰性。

  3. “Zig is faster than C++, …Finally, we did get a catch … You’d think we would then remove my phone number, but we just commented it out, so it’s shipped, and it’s in all the damn source code leaks for NT that are out there”

    中文意译: “等到 Bug 追踪成功时,人们理应删掉我的私人电话号码作证,但我们只是把它注释掉了,所以它就这样随代码发布了,现在所有 NT 的泄露源码里都留着我的号码。” 语境: 讲述他利用 Windows Task Manager 中的断言机制(debug phone number)成功定位内核 bug 的经历,既幽默又体现了 Debug 痴迷者的另一面。