我第一次写代码，是大二那年。
一门叫“数据结构”的课，老师布置了一道作业。我在宿舍里熬了一个通宵，键盘一直敲到凌晨三点。屏幕上的报错改了一个又一个，程序终于跑起来，输出了一行正确的结果。
我靠在椅背上，盯着那行字看了很久。
那种感觉直到现在还记得。不是剧烈的兴奋，更像一种安静的满足。一个原本只存在于脑海里的东西，被我一点一点搬到了现实中。
敲下最后一行代码之前，它还只是一个模糊的想法。
然后我按下运行。
它活了。
后来我成了一名程序员，写了十年代码。
有些系统顺利上线，有些项目停在半路；有些功能曾经被很多人使用，后来又被新的迭代悄悄替代。那些在深夜里反复排查的问题，当时仿佛占据了整个世界，几年以后再回头看，也许只剩下版本记录里一行早已说不清来历的提交。
代码是一种很容易消失的东西。
它会被重构、删除、覆盖，也会随着一套系统下线，从此无人问起。
可那个凌晨的感觉，始终留了下来。
我第一次知道，一个人可以把看不见的东西，变成某种可以运转、能够被别人使用的东西。
很多年后，我开始写文章，才发现自己似乎又回到了那个夜晚。
还是一块空白的屏幕。
还是一个尚未成形的念头。
只是这一次，我要写的，不再是给机器看的语言。
开始带小组，是工作第四年的事。
第一次做技术负责人，小组里加上我一共五个人。年纪最小的同事刚毕业，连Git都用得不太熟。我一边写代码，一边带他了解系统；一边赶项目进度，一边做构建评审。
那一年，我写了很多代码，也第一次认真写了很多文档。
以前我不太喜欢写文档。
，真正的工作是将功能做出来。文档只是代码之外的附属品，是项目结束后为了让流程显得完整而补上的东西。有时间整理文字，不如多写几个API，早点让系统跑起来。
可后来我慢慢发现，文档写得清晰的项目，代码往往也更稳定。
不是因为文档本身有什么魔力，而是写文档的过程，会逼着人提前面对那些原本藏在脑海里的问题。
为什么要做？
真正要解决的是什么？
系统的边界在哪里？
如果依赖失败，如果规模扩展，原来的设计还能不能成立？
这些问题停留在脑海里时，总显得早已有了答案。人很容易把一幅大致的画面，误认为完整的设计。直到真正开始写，才会发现有些地方只是凭经验跳了过去，有些结论之间缺少桥梁，还有些所谓的“想清楚”，不过是一团尚未被命名的感觉。
写下来，模糊才开始显形。
一句话接不上下一句话，通常不只是表达的问题，而是中间缺少了一段逻辑；一张结构图解释不清某个箭头，也许意味着系统的责任边界根本没有想明白。
文档不是对思考的记录。
很多时候，文档就是思考发生的地方。
它让一套逻辑在进入系统之前，先在文字里运行一次。
我也见过许多跳过这一步的项目。
需求一来，小组立刻开始开发。页面很快搭起来，接口也陆续做完，最初的进度看上去非常快。
直到项目走到中间，那些一开始没有回答的问题才逐渐出现。
这个状态到底由谁维护？异常之后应该重试还是终止？上下游为什么对同一个字段有不同理解？最初以为只是一个简单功能，为什么改动沿着依赖一路扩散，最后牵动了半个系统？
于是大家开始返工、重构、补边界，重新解释那些原本以为早已完成共识的需求。
开始时“节省”的思考时间，最后以更加昂贵的方式被重新支付。
有些时间并没有真正省下来。
它只是变成了债，带着利息，在项目最忙乱的时候回来。
从那以后，我经常要求小组先写构建文档。
不是为了留档，也不只是为了让我评审，而是让写的人先看见自己的想法。
如果一件事无法被清楚地写下来，它通常也还没有清楚到可以被实现。
这并不是说，必须等所有问题都有答案以后才能动手。系统永远不可能在纸面上被完整推演，很多问题也只有真正进入现实才会出现。
但至少在第一行代码出现以前，我们应该知道自己为什么出发，准备走向哪里，又有哪些地方仍然没有答案。
后来开始写文章时，我重新遇见了同一个问题：
你真的想清楚了吗？
有一段时间，我很迷信工具。
我折腾过许多笔记软件，也认真研究过各类写作方式。从印象笔记到Notion，再到语雀，我配置目录、建立标签、寻找模板。
每换一个工具，我都会产生一种新的生活即将开始的错觉。
页面足够整洁，工作流足够顺畅，仿佛只要目录足够清楚。
后来发现，并不会。
工具可以降低阻力，但不能替人写下第一句话。
有时候，准备甚至会变成一种精致的逃避。我们不断调整环境、研究方法、搭建系统，以此获得一种“已经开始”的满足感。
可文档始终是空的。
这和写代码时反复研究系统有些相似。
技术选型当然重要。但如果小组始终停留在比较工具，却迟迟没有开始验证最重要的问题，那么再完善的选型，也许只是推迟面对现实的方式。
工具解决的是“怎样写得更顺”。
它无法回答“你为什么要写”。
往往不是找到最好的软件，而是在某个普通的晚上坐下来，打开一页空白文档，真正让一篇文章出现。
有了第一句，才会有第二句。
有了一个粗糙的迭代，才有机会修改。
一个没有写出来的完美想法，最终仍然什么都不是。
我的第一篇文章写了很久。
反复修改，反复怀疑。今天觉得太浅，明天觉得太散；删掉一段，又担心文章失去了原来的意思。
迟迟不愿意发出去，是因为总觉得它还可以更好。
后来有一天，我还是按下了发布。
那一刻有一点像大二那年的凌晨。只是屏幕上不再出现“运行成功”，也没有任何验证告诉我，这篇文章究竟对不对。
它并不完美。
可它存在了。
它从一个只有我知道的念头，变成了一件能够被别人看见的东西。至于别人会怎样理解，哪些句子会被记住，哪些地方会被略过，早已不再完全由我决定。
文字一旦离开作者，就开始拥有自己的路。
这对一个习惯了控制输入与输出的工程师来说，是一种陌生的体验。
也是一种松动。
后来我才明白，写代码和写作虽然都在把不可见的东西搬到外面，却考验着人两种几乎相反的能力。
代码要求你不断压缩歧义，直到一件事能够被机器精准执行。
文字却不必封闭所有含义。它需要足够清晰，让人能够进入；也要留下一点空白，让另一个人能够带着自己的经历继续往前。
一个教我怎样把世界说明白。
另一个教我承认，世界并不总能被说明白。
写代码时，你必须把逻辑翻译成明确的条件、变量和边界。输入是什么，一种状态怎样走向下一种状态，输出是什么。
写作也在进行一种翻译。
只是它翻译的，往往不是完整的逻辑，而是那些尚未被整理好的感受、犹豫和心得。
你以为自己想写的是一个观点，写到中间才发现，真正牵动你的或许是另一件事。你原本想印证一个结论，写着写着，却看见了它背后的迟疑。
因此，写作并不只是把早已想好的内容誊写一遍。
它更像在一间没有开灯的房间里缓慢行走。文字照到哪里，你才第一次看见那里原来放着什么。
有些东西在被写下以前，连自己也不知道它存在。
我曾经以为，代码主要是写给机器看的。
后来带小组久了，才明白，机器只是执行代码，真正需要阅读代码的，是人。
几个月以后接手这段代码的人，需要从命名、结构和注释里理解，当时的人为什么这样设计，哪些边界不能越过，又有哪些看似多余的判断，其实是在保护某种曾经出现过的异常。
好的代码，不只是让机器正确运转。
它也在向后来的人解释自己。
从这个意义上说，程序员始终都在写作。只不过我们使用的是一种更严格的语言，读者既有机器
ID:1218
