前言

以前有过一个设想，假如一个普通程序员，愿意花费 5 年的时间专心学习和研究某一个技术框架，比如 Spring Boot，5 年的时间足够了解这个框架的多数细节了，那么他在 5 年之后，可以凭借对 Spring Boot 足够深入的了解，写一本《Spring Boot 从入门到精通》之类的书没有问题吧。写出一本书可以带来什么？至少可以增加一些被认可的依据。“写书“的难度大吗？看看现在中文的技术类书籍，哪个不是电子垃圾？然而事实上，大多数 5 年以上工作经验的程序员都做不到“写书“这件事。即使写的难看，毕竟也是有，聊胜于无啊！为什么没有人写？

有多少书写着写着就变成了技术手册？大而全没有重点，有用的没用的全写进去。也许是本着对观众负责的态度，“我写的内容不一定有见地，至少全啊！“这样的逻辑类似于，消费者在买东西的时候，“这个功能我可以不用，但不能没有！“

我也想制造一些电子垃圾了，就像各种无聊的技术博客文章的集合。现在是 2021 年的国庆节假期，正好有时间可以思考一下这件事情。

书的内容会和 Blog 冲突吗？如果有有意思、值得写的东西，应该优先发到 Blog 上。好像也是，不过 Blog 上的内容更多是描述个人经历、表达态度和观点，一直都无法专注尤其是低质量的技术内容。Blog 的内容往往需要字斟句酌，可能最终看到的只有 100 个字，但实际上也许想了 1000 个字，思考好几天，然后去掉不合适的措辞、精简内容、明确清晰观点，剩下了少数简练但有用的内容。

书的内容会更随意一点，为了节省时间，也尽量避免对内容的反复修正。总得有一些新的事情做，这些事情总需要一个开始，你不能等所有材料都准备好了才下锅。如果以后有一天，我有足够写出有价值书的能力，可能就不想写了。

书名借鉴了 Ground-up Computer Science，我暂时没有更好的主意了。内容会聚焦在 Blockchain 上，这个应该没什么问题，这个方向的水很深，有足够的内容可以写。也不需要太多担心机会成本的问题，其他领域并没有更好的选择，

在用语上，可能会直接用一些简单的单词。因为经常出现的情况是，在阅读其他资料的时候看到了某个词并且留下了印象，然后就直接拿来用了，不希望刻意在头脑里翻译一下。比如，这本书的内容没有 magic，就是一些普通的技术大杂烩。

这件事情的周期可能会有点长，预计 1 ~ 2 年左右。希望在 2023 年年底之前，这本书的内容可以初步让自己满意，可以归档 0.9 版本。差的 0.1 用来勘误。

书里具体的内容以思路为主，我们从小就知道“画一条线 10000 美元“的故事，画一条线价值 1 美元，知道线画在哪儿 9999 美元。故事也许不是真的，但故事广为流传，侧面说明故事中的逻辑至少有道理。把代码写出来，远不如知道为什么要写，解决了什么问题，有没有更好的解决办法。

书的目录结构可能杂乱无章，因为不太希望按照结构化知识的方式组织内容，一方面不好操作，有些东西不好分类，另一方面，结构化组织内容的实际效果不一定好，反而会由于一味最求全面而忽略思路和细节。世界上没有“最全“的一个状态。内容可以是主题式、时间线式或者随心所欲的。

按照同样的逻辑，也很容易有 Ground-Up Golang、Ground-Up Programming 之类。Talk is cheap, just do it first.