AWS工程师憋了3年没写博客，终于摊牌了

一个每天写Rust、刷Codeforces的AWS工程师，公开承认自己在"等"。

等什么？等自己"足够懂"再开口。结果那个门槛越抬越高，三年过去，文档库里堆满了私有笔记，博客页面还是空的。EJ，亚马逊云服务的软件工程师，上周终于发了第一篇文章。标题很直白：《Why I'm Finally Starting to Write》。

这种"准备强迫症"在技术圈传染率极高。

我们采访过十几个五年以上经验的老兵，超过半数承认自己有过"等准备好了再输出"的阶段。有人等了两年，有人等了五年。EJ的解法很程序员：把写作当成debug工具，而非教学成果。

从竞赛编程里偷来的方法论

EJ在Codeforces上泡了很久。这是个俄罗斯办的算法竞赛平台，全球几十万程序员在上面刷题排名。他发现一个反直觉的规律：卡壳最久的题目，往往不是算法不会，而是脑子里的模型差了一层。

「写一份干净的解法解释，哪怕只给自己看，也能逼出那些缝隙。」

这是EJ的原话。他把写作当成强制澄清（forcing clarity）的手段——不是教别人，是给自己做代码审查。这个视角转换很关键：从"我够不够格"变成"这能帮我debug吗"。

竞争编程圈子有个老梗：会做题的不一定会讲题，会讲题的一定真懂了。EJ想把这个过程公开化。

生产级代码是最好的教材

EJ的学习路径很"脏"。

不看教程，直接读Tokio、Firecracker的源码。Tokio是Rust异步运行时的事实标准，Firecracker是AWS用来做Lambda和Fargate的微型虚拟机，启动时间125毫秒。这两个项目加起来几百万行Rust，文档散落各处，注释里藏着无数设计决策的尸检报告。

「读生产代码比任何课程教得都多。」

他列了几个具体想挖的问题：S3怎么保证 durability（持久性）？Tokio的调度器下一帧跑哪个任务？Firecracker那125毫秒里发生了什么？这些问题Stack Overflow上没现成答案，需要翻论文、读源码、跑实验。EJ的选择是：把挖掘过程写下来，而不是让结论烂在私有笔记里。

这种"过程写作"在技术传播里很稀缺。

多数技术博客是"我解决了X"，很少见"我花了三周理解Y，这是死胡同A、B、C"。后者对读者的价值往往更高，但写起来更耗 ego——你得承认自己绕了弯路。

没有排期，不设边界

EJ给博客定了个很松的框架：系统、Rust、竞赛编程，偶尔聊聊边工作边读硕士的体验。九月他要入学佐治亚理工的part-time硕士项目，"显然我喜欢忙一点"。

没有发布日历，没有垂直定位。这种"反运营"姿态在2024年的内容环境里显得有点奢侈。但换个角度看，这也是技术写作的某种回归：先有真问题，再有输出，而不是反过来。

他的第一篇文章底下有条评论被折叠了，系统提示"Are you sure you want to hide this comment?"——典型的博客平台默认交互。没人知道那条评论说了什么，但这个细节很有意思：EJ选择的发布平台（看起来是某种静态站点生成器配评论系统）本身就带着旧互联网的遗迹，没有算法推荐，没有流量焦虑。

写作动机从"建立影响力"滑向"整理认知"，平台选择也跟着变了。

我们翻了EJ的GitHub和LinkedIn。Codeforces评分1900+，AWS两年，本科CMU。履历够亮，但他显然没打算拿这个开道。文章里没提任何头衔，自我介绍只有一句"a software engineer at AWS"。

这种克制本身是种筛选：读者要么对125毫秒的虚拟机启动时间真有兴趣，要么划走。没有中间地带。

EJ在文末留了句很轻的邀请："If any of that sounds useful, stick around." 没有订阅按钮，没有社交媒体链接。 stick around，留下来。这个短语在英语里带点老派味道，像是书店老板对进门客人的随口一说，不指望回应。

技术博客的死活周期通常两年。第一年热情高涨，第二年更新稀疏，第三年域名过期。EJ能写多久不知道，但他至少解决了一个入门难题：把门槛从"值得被阅读"换成"能帮我自己想清"。

后者永远达标。

你上一次因为"想清某个问题"而写作，是什么时候？