站在网络与技术前沿的不少开发者们，还保持着如今看起来略显古早的 Web 2.0 时代行为——写博客。

技术博客写作是工程师们沿袭已久的传统。对于各种代码段、架构图，和层级分明的逻辑推导过程来说，技术文章无疑是一种经过检验的有效交流方式。

写技术文档则是工程师们的另一种日常。面对技术文档，有人投入，有人头疼。写代码与写文档，到底能不能够获得和解？

本期读书日特辑，我们邀请到一位收获了不少读者的 Shopee 工程师，来和大家一起聊聊技术写作这回事儿。

Draven 是来自 Shopee Engineering Infrastructure 团队的后端工程师。在工作之余，他还拥有另一重身份——技术写作者。

如果你恰巧读过「面向信仰编程」的博客文章，没错，Draven 就是那位不愿透露姓名的博主。他在博客分享自己的技术学习笔记，和对程序设计原理的思考，还有发布后大受欢迎的技术文章配图指南。

从博客中可以窥得 Draven 对系统性思考与总结的偏好。他写系列文章，从「为什么这么设计」到「看看论文」；他在学习与探索 Go 语言的过程中，将思考剥离为文章，开源成电子书，又在 2021 年末集结成册，出版纸质书。

如何从写博客到出书？写技术文章究竟带来了什么？又怎样快速接触新的知识？以下是 Draven 关于技术写作与知识获取的分享。

Q：先简单介绍一下自己吧 :D

A：我是 Draven，很多人可能都是通过我的博客听说我的。在大学期间主要学的是软件工程，大学四年基本都是在做 iOS 客户端开发，毕业之后就开始做后端开发，做过交易所、也做过调度系统，近两年主要做 Kubernetes 相关的开发工作。目前对云原生、操作系统内核都比较感兴趣。

Q：最开始写技术文章的时候，应该还是在校时期？当时是怎么决定要开始搭建博客？受谁的影响比较大？

A：开始写博客的时候应该是在大二，原因也比较简单，当时受到学长的影响，提到写博客对以后找工作都比较有帮助，所以自己就开始折腾博客了。比较早的时候是当做笔记来写的，后面发现博客有了读者，就把之前个人觉得价值比较低而且没什么人看的内容都删掉了。

Q：你在一篇博客文章中提到，把「提高技术影响力」加入了自己的 OKR，今年的 OKR 里还有这一项吗？替读者们问一下，为什么坚持写了好几年的博客这几个月停更了？

A：今年的 OKR 还是有这一项的，只是具体内容在完成或者到 Deadline 之前就先不说了。这半年的很多业余时间都在准备《Go 语言设计与实现》的出版，而且作为内容的创作者来说，不是任何时候都是有表达和分享的欲望以及内容的，博客连着写了五六年的时间，自己逐渐对之前想要分享的题目失去了兴趣，所以想找一些新的方向和内容。

Q：《Go 语言设计与实现》从电子书落地为纸质书的过程中，有着怎样的经历？能否简单讲讲从自己写书到出版社出书的故事？

A：在博客上开始写这本书其实有两个原因：首先，刚刚开始写这本书的时候，市面上其实没有太多分析 Go 语言的博客和书籍，所以希望能够完成一系列有相关性以及完备的内容；其次，自己刚刚接触 Go 语言，也希望借助这本书的写作加深自己对 Go 语言设计和实现的理解。

相信很多书的作者都会提到，完成一本书真的是一项很大的工程，从最开始凭借着一腔热血和激情是可以写出很多内容的，但是随着战线拉得越来越长，一旦这口气断掉就很难接上来。我在这本书的写作过程中也想到过放弃，因为对 Go 语言了解足够多之后，就失去了最开始的那种兴奋，我们享受的是这种探索的过程，然而写作真的是痛苦的，尤其需要重复劳动，在一个主题中写出几十篇能够达到出版质量的内容。

在很长的一段时间内，都有各个出版社的编辑老师联系我考虑要不要出版，但是当时实在是不愿意再花更多的时间来完成这个主题，大量的时间都花在了「为什么这么设计」系列文章上了，所以一直都没有考虑过出版的事情，直到 2020 年的 2 月份才跟图灵社区的编辑老师达成了出版意向，这其实也是觉得自己没有足够的动力来完善整本书的内容，希望找一个外部的力量监督自己写完这本书。

Q：你前面提到「在一个主题中的重复写作是痛苦的」，但实际上你在博客写作中也规划了主题，例如「为什么这么设计」系列。写书和写博客，两种主题写作的最大区别在哪里？它们享有同一种痛苦吗？

A：写书和写系列博客都是内容的写作，前者往往需要内容有更强的相关性、连续性以及足够的篇幅，这也需要持续对同一内容进行输出，因为我们在写书的过程中有很明确的目的性，所以这个周期是比较漫长和痛苦的，不容易坚持下来。不过也正因为困难，你在完成后得到巨大的成就感，也会释放很多压力。

后者更像是对一组博客的分类和整理，它没有明确完成的时间点，所以写起来反而会更随意，少了很多压力，如果实在觉得这个主题写不下去了，换一个主题就可以了，倒是没有写书的过程困难。

Q：在工作之余写博客、写书，做技术分享，有没有计算过在这一类事情上投入的时间成本？让你持续下去的动力有哪些？

A：写博客和写书对于自己来说其实是一个输入和输出同时进行的过程，这些付出的时间最终都会回馈到自己身上，你会发现原本自己认为已经掌握的知识其实并没有掌握，缺失的细节会在这个过程中补齐，这个过程需要我们严格遵循因果关系，得到合理的逻辑链条，这样才能真正得到相对正确的知识。

Q：结合自身经历，你怎么看待技术写作/技术分享对 Developer 的收益？

A：提到技术写作、技术分享的收益，很多人首先提到的都是技术影响力，这里不想谈关于技术影响力这个听起来比较虚的话题。这里更实际地介绍一下，这件事情对我们的个人能力，尤其是对自己带来了哪些改变。

技术写作并不是少数人才会做的事情，我们输出的技术方案和文档都需要掌握一定写作的能力，如何写出符合认知、易于理解的文档，在工作中是与写代码同样重要的，我一直都认为能写好代码的人一定能写好文档。以个人为例，如果现在重新读以前写的博客，会发现以前的文章逻辑不够缜密，结构也不够严谨，今天在写作时会更加注重结论的推导过程，与过去相比是能感觉到明显有提升的。

我们使用树形的结构写代码，控制组件的依赖关系，也同样用树形的结构写文章，降低读者的心智负担，这些都是相似的。之前看到过一句话，写得非常好，在这里分享给大家：「写作之难，在于把网状的思考，用树状的语法结构，转换成线性字符串。」

Q：从博客中可以看到，你最开始做 iOS 开发，然后去写了 Ruby on Rails，后来也折腾过 Java，到 2020 年担任 K8s Scheduling SIG 的 Reviewer，方向转变的过程中觉得最困难的是什么？以及如果有的同学想转到一个感兴趣，但却在日常工作中接触不到的方向，有什么样的建议？

A：方向转变的过程中，我们遇到的问题应该都是相似的：如何凭借已经有的知识快速探索新的领域。

如果想转到一个感兴趣的方向，建议用好搜索引擎搜索该领域的关键字，然后用深度遍历和广度遍历的方式逐一研究搜索出的结果，快速筛选信息，在这个阶段只要肯花时间，提升是非常快的，学习新知识可能会痛苦，但是探索和收获的过程一般都是快乐的。

Q：接触新的技术栈时，你会如何掌控自己的学习路径？在学习的过程中，参考他人的相关文章、书籍或是社区中的经验交流，起到了多少作用？

A：这两年接触新的技术栈一般都比较功利了，平时只会去了解这些组件能够做什么，只有真正用到的时候才会边用边查，也是因为时间相对有限，没有太多大块的时间能够集中阅读书籍，所以挑选书的时候也比较谨慎。

参考他人的相关文章、书籍或是社区中的经验交流还是很有用的，不过还是要感谢搜索引擎把这些优质的内容推送到我们的结果中。

Q：最近在读哪些书或者论文？能推荐一些吗？

A：最近在重新学习一些操作系统、网络和 C++ 的知识，在看《UNIX 网络编程》《Effective C++》。论文的话可以看一下去年的 SOSP '21，我比较关注调度、分布式系统这些方面的内容。

一本从底层原理讲起的书：

作者：Draven

出版年份：2021年11月

出版社：人民邮电出版社

本书几乎涵盖了 Go 语言从编译到运行的方方面面：调试源代码、编译原理、数据结构、语言特性、常用关键字、并发编程、内存管理、元编程和标准库。

通过阅读，你将能理解 Go 语言的实现细节，认识设计背后的原理，提升阅读源代码的技能。

祝愿各位读者

多读书、读好书

写代码、写文档 buff +++！

☟☟ 一键拥有