Matt Pocock:成为真正软件程序员的三个台阶,你爬到了哪一级?

hello！大家好！

这两天在刷社交媒体的时候，看到技术圈知名布道师 Matt Pocock 发了一条很有分量的推文。

经常折腾前端和 TypeScript 的同学对这个名字应该不陌生：他是《Total TypeScript》的作者，也是 AI Hero 的发起人，之前在 Vercel 担任过开发者布道工程师（Developer Advocate）。有意思的是，他在成为程序员之前还做过声音教练。他平时讲技术很擅长把极度抽象的概念，用朴素且直白的话传授给听众，很多人喜欢他的教程。

这次，他没有聊 TypeScript 的奇技淫巧，而是写了一段关于**“如何成为一名真正的软件程序员”**的心得：

看到这段话的时候，我坐在屏幕前被深深触动到了。

结合我自己过去这些年折腾各种个人项目、开源工具以及给团队搭基建的经历，今天也想顺着 Matt 提到的这三级台阶，逐段对照他的英文原文和心得，和大家聊聊这段充满挫败感却又极其迷人的进阶过程。

很多人学编程的第一步，都是从“给自己做个工具”开始的：

一个抓取特定新闻的爬虫脚本、一个自动重命名文件的命令行小工具、或者一个根据自己喜好定制的个人博客。在这个阶段，写代码的感觉是非常爽快的。因为需求是你自己提的，逻辑是你自己自洽的，测试也是你自己肉眼完成的。

但这也正是 Matt 随后直接给出的冷酷判断：

这句话听起来可能有点刺耳，但其实极其切中要害：我们在面对自己写的产品时，宽容度是无限高的。

举个很实际的例子：你自己写的一个脚本，如果偶尔报个异常，你会下意识地心想“哦，这里是因为参数没填完整，我知道怎么绕过它”；如果界面排版错位，你会自我安慰“反正在我自己的屏幕分辨率下看着挺正常的”；如果数据偶尔丢了一条，你甚至会直接打开数据库手动补上就得了。

你对这个工具的脾气、输入范围边界了如指掌。某种意义上，你是在溺爱一个只有你能伺候的“偏科孩子”。

在这个阶段，哪怕你把语法背得滚瓜烂熟，或者能熟练调用各种前沿 API，严格意义上说，你依然只是在玩具箱里堆积木。只要软件没有离开你的电脑屏幕，它就从来没有真正接受过真实世界的“风吹雨打”。

于是，Matt 给出了第二个关键台阶，以及他对新手开发者最真诚的建议：

哪怕测试者只有一个同事、一个朋友，甚至是你的家人，只要这个人不是你自己，整个工程的重力法则就会瞬间改变。

前段时间我自己折腾了一个小而美的桌面端截图工具。

最初在我自己的电脑上，用得那叫一个顺手：按下快捷键、框选区域、贴图置顶，整套逻辑行云流水。因为我自己写的底层逻辑，我深知什么分辨率下抓取最丝滑，也知道按 ESC 键能直接取消，甚至觉得这小工具已经完美到可以随时发布了。

直到我兴冲冲地把它打包发给身边的几个技术朋友试用。

刚发出去不到半天，各种意料之外的反馈就迎面砸了过来。其中有两个问题非常细微，我平时自己用的时候完全忽略了，但对真实用户来说体感极差：

第一是多显示器与不同缩放率（DPI）下的抓取错位。我平时用的是单一外接 4K 屏，习惯了固定的缩放比例；但朋友们有的用双屏，甚至一边是 200% 缩放的笔记本内屏、一边是 100% 缩放的老显示器。光标从主屏一滑到副屏，框选蒙层当场错位、截出来的图直接变成了局部放大马赛克。在自己电脑上“坚如磐石”的代码，换个硬件环境瞬间稀碎。

第二是剪贴板写入与写入冲突。我自己截图后往往习惯等一秒再粘贴，但很多用户的肌肉记忆是“松开鼠标的同时立刻按 Ctrl+V”。由于我没有处理系统剪贴板异步占用的重试与锁保护，在短时间内高频截图或者配合其他剪贴板管理工具使用时，偶发性地会贴出上一张旧图，甚至直接把系统剪贴板卡死报错。

更让我受打击的还有一个 UI 上的分歧。

为了让工具看起来足够“极简、不打扰”，我特意把截图工具栏设计成纯黑底色、只有 20px 高的极小悬浮条，所有操作按钮都用极为收敛的淡灰色极细线性图标，没有加任何边框和文字阴影。

在我的深色壁纸高刷屏上，我觉得这个设计“克制、高级、高级感拉满”。

结果几个朋友一上手，反馈惊人的一致：“这工具栏根本看不清啊！”

那一瞬间的感觉真的很微妙：尴尬、沮丧，甚至带着一丝创作者的委屈：“我觉得挺精致好看的啊，你怎么完全不理解这种极简美学？”

但这就是现实：你以为的审美克制，在不熟悉你思维模型的真实用户眼里，往往就是“不好看、不舒服、反人类”。

这完全印证了 Matt 说的下一句大实话：

当你的软件要服务于第二个人时，你被迫要开始处理以前根本懒得管的边界：跨屏多分辨率适配、操作系统底层 API 的竞态保护、不同环境下的视觉对比度与交互容错。这个过程会让你彻底清醒，但也正是从这一刻起，你才真正开始建立起对“流程”和“质量”的敬畏心。

如果你能耐着性子跨过第二步，让一群人持续、稳定地使用你的工具，你才真正拿到了通往第三步的门票：

到了这个层级，游戏的规则再次发生质变。

面向大众的软件，意味着你的用户群体不再有熟人滤镜，没人会在群里温和地给你提建议。用户遇到白屏会直接关掉网页走人，遇到报错会在社交媒体上毫不留情地公开吐槽；更危险的是，公网的环境充满了恶意探测、暴力扫描、供应链投毒和并发流量洪峰。

在这个阶段，单纯的代码编写往往只占了整个工程的 30%：

• 你不仅要写出能跑通的功能，还要考虑版本平滑迁移与数据库向下兼容；
• 你要面对各种冷门机型、奇怪浏览器内核与弱网环境的兼容性灾难；
• 你要建立起完整的监控告警（On-call）、自动化测试链路与灰度发布机制。

任何一处微小的逻辑漏洞，在成千上万用户的放大镜下，都会变成毁灭性的灾难。

很多没有经历过这个阶段的同学，往往很难理解“一小撮人用”和“成千上万人用”到底有着怎样天壤之别的鸿沟。

当你的软件只有几十个内部测试者时，系统的整体运行几乎都在可控的概率范围内。但当用户规模真正跑起来之后，长尾效应（Long Tail）就会把所有极其微小的可能性无限放大：那些在百万分之一概率下才会触发的内存泄漏、特定输入法快捷键的全局冲突、极端弱网环境下的数据竞态、或者某个小众定制 Android 系统的显存崩溃……在小范围内永远不会出现的偶发怪病，在成千上万真实用户的日常使用中，每天都会扎堆冒出来。

在小范围阶段，这类小细节哪怕偶尔露头，开发者也往往会下意识地觉得“这只是个例，刷新一下就好”，根本提不起重视；可一旦面向公众，这些微小的噪点就会迅速演变成雪崩般的客服工单和负面评价。

说实话，我自己目前做的产品依然只在身边一小群朋友的范围内使用，并没有真正经历过数万人乃至更高量级的公众风暴。

但是在不久之前，我倒是和一个在大厂工作过的朋友聊过相关的话题。

他跟我说，一旦软件做到千万级用户的体量，你面对的就完全是另一个物种了。每天都会冒出各种各样以前闻所未闻的奇葩问题、奇葩需求，还有各种各样让你哭笑不得的奇葩用户操作 😆。

这跟以前做几个小工具、供身边十几个人用有着本质的区别。在极庞大的人群基数下，再冷门的边缘场景、再刁钻的网络和设备环境，都会被真实地组合出来。排查和兼顾起来确实琐碎又磨人，但用他的话说：“虽然过程极其折磨，可当你最终把这些暗坑一个个趟平，看着大盘曲线上几十万、上百万人能够平稳顺畅地用着你的系统时，那种踏实的成就感，也是做个人小玩具永远无法体会到的。”

很多人问：在今天这个 AI 能随手写出几百行代码、一键生成精美前端页面的时代，成为一个“真正的程序员”门槛到底是在变高还是变低？

我觉得 Matt 在推文结尾给出的那两句话，就是最好的回答：

AI 可以把第一步（构建个人软件）的门槛降到极低，只要你有一个想法，甚至不需要精通语法，几分钟就能拼出一个跑得通的雏形。

但从第一步走向第二步、第三步的过程，AI 却无法替你完成。大模型无法替你承受朋友当面挑刺时的沮丧感，无法替你感知真实用户的迷茫与困惑，更无法替你培养那种在复杂网络环境下小心翼翼、防御性编程的工程嗅觉。

找一两个真实的测试者，把你的玩具推给他们用一用。去听听那些刺耳却真实的吐槽，然后耐着性子，一行一行地去加防御代码、去修交互细节。

这个过程确实令人沮丧、缓慢且费力。

但正如 Matt 所说 —— That's programming.