Technical Writer 需要 Technical 到会

Foreword

最近有一位读者向我咨询了一个关于 Technical Writer 技术知识储备的问题。

她是一名即将入职的应届毕业生，工作正是 Technical Writer。她因为自己是文科生，对于技术知识方面还是有点担心，所以来向我咨询 TW 对于相关技术知识的储备是否会有很高的要求。

是啊，Technical Writer 这个职位中的 Technical 到底蕴含了哪些要求呢？

对于这个问题，其实只要你有很强的快速学习能力，那就不是问题了。很多 Technical Writer 都是文科背景，也没有接触过工作所属领域的技术知识。但只要在工作许可的时间内快速掌握一定的专业技术知识，并保持积极学习的心态，即可满足工作需求。

我在之前的深度解析关于技术翻译的六个认知误区中，提到的“误区 5：技术翻译人员必须是高度专业领域的专家”，与这里 TW 的技术知识要求也是相通的。

那么，专业技术知识到底要掌握到什么程度呢？怎么知道自己的知识储备是否足够了呢？Technical Writer 又是否需要 Technical 到会写代码呢？

其实，你很容易就能得到答案。关键词：需求。

技术知识因需求而定

不同的行业、不同的公司、不同的技术文档类型，对于 Technical Writer 技术知识的要求也会不同。

如果你已经是一名 Technical Writer，思考一下自己所在岗位的工作需求，再反观一下自己的知识储备，就知道自己掌握的知识是否已达到可胜任工作的程度，是否已足够。

如果你是尚未进入这一行的小伙伴，或许不能那么直接地了解工作需求，可以参考招聘帖上的任职要求和岗位职责，也可以咨询相关行业的小伙伴。

至于 Technical Writer 是否需要会写代码，也是由需求而定的。基本上，掌握一些简单的命令即可满足工作需求，并不需要你精通某种编程语言。

假如你只负责 Release Notes，那你就用不着；假如你是硬件设备的 Technical Writer，那也不会涉及写代码；假如你是某个相对较新的软件产品的 Technical Writer，例如数据库产品的部署文档，那可能就需要用到简单的命令去测试。

当 Technical Writer 需要与代码亲密接触

现在是举栗子时间：

笔者所在的领域是数据库，大部分日常工作都是围绕数据库的，采用的文档更新模式为 GitHub + Markdown。

公司的产品是开源分布式 NewSQL 数据库 TiDB，主要包括三大组件。前短时间，笔者接到的文档需求是给其中负责存储数据的组件 TiKV 写单独的文档，因为在某些场景中用户也可以单独使用这一组件。

于是，便开始了一个技术写作的流程，不只是写某一个文档，而是包含设计文档架构的一个流程。

关于完整的流程，在之前跟大家分享的技术文档诞生记 | 完整的技术写作流程是怎样的？ 中有过详细的描述。无论是需要写一篇新的文档，还是要设计文档架构并写一系列文档，流程都是类似的。

因为 TiKV 独立使用的部署方式还没有测试过，所以即便跟技术小伙伴咨询了大概的步骤之后，也还是需要自己测试一下，以确保你写的文档是正确可用的。另外，可能还会发现一些问题，例如哪些内容不适合放到部署文档里，哪些是用户在安装部署时很可能会遇到的问题。

接下来跟大家分享一下我在测试 TiKV 安装部署方式中的一些体验：

1. 不要排斥代码，其实还蛮有意思。

这里的安装不同于我们常用的下载下来一个可执行文件，然后点击两下就可以了；而是需要你准备不同操作系统的机器，部署环境，还涉及编辑一些文件等。

这种安装部署是在一个终端里进行的，所以即便有了参考步骤之后，也必定要用到一些简单的其它命令来辅助，而这些很可能是文科背景的 Technical Writer 所不知道的、压根没接触过的。

测试部署方式的时候，我的电脑屏幕经常是像这样的，有时是一块，有时切分成四块，有时切分成六块：

其实，那些简单的命令学起来挺容易的，记不住的话至少可以先整理到一个地方记下来。下次用到的时候，就不必再次搜索或者求助他人了。

2. 测试多种部署方式，理清步骤。

产品提供了多种不同的部署方式，都要进行测试。例如：通过自动化部署工具 Ansible，通过 Docker Compose，通过 Docker，通过 Binary Files。有的适用于开发测试，有的适用于生产。

因为我自己的电脑是 macOS 系统，测试需要用到主要是 Linux 系统，所以需要使用虚拟机或其它物理机。有的部署需要一台机器，有的需要四台，有的需要六台。

自己亲自测试一遍安装部署，对整体步骤就有了一个清晰而直观的了解，这样写起文档来就很容易下笔了。这也正是技术写作中很重要的一点：只有真正理解了，你才可能写出好的文档来。

3. 遇到许多问题，邂逅各种报错信息。

在测试部署的过程中，遇到很多问题以及各种报错。有的是与基本技术知识相关的，有的是一些客观原因如虚拟机上的网络访问，有的是一些参数配置问题。

这是一个体验用户可能遇到的各种报错信息的机会，还可以顺便了解下当前的报错信息是怎么写的：

满屏的红色：

当看到 "Congrats! All goes well. :-)" 时，内心总是无比欣慰的：

4. 如果自己再懂的多一点儿就好了。

在这次测试安装部署的过程中，遇到问题时除了自己搜索外，也向技术小伙伴寻求了不少帮助，学习到了一些简单常用的命令，增加了对数据库部署的理解。

同时，我对自己所在岗位潜在的技术知识需求也有了更清晰的认识，可以将在这次部署中用到的技术知识做一些整理、巩固和扩展，以备之后有需求时更顺畅地完成，也不用频繁地麻烦技术小伙伴了。

Afterword

总之，Technical Writer 需要根据具体的岗位需求来快速学习和补充自己的技术知识。对于我的岗位来说，就需掌握一些简单的命令，如果大家对常用的简单命令比较好奇，之后也可以跟大家分享一下。多学习一些工作或兴趣相关的东西，说不定什么时候就用得着啦。

俗话说，技多不压身。但也有人说，艺多不养人。我个人觉得，“博学”一点儿也挺好。Be a polymath（博学的人）. 最近正好在 Medium 上看到一篇有趣的文章，标题叫做 People Who Have “Too Many Interests” Are More Likely To Be Successful According To Research。

此文算是对传统的 "Jack of all trades, master of none." 的反驳，其中列举了 7 个 Polymath 的优势。感兴趣的小伙伴可以去读一下。链接：https://medium.com/the-mission/modern-polymath-81f882ce52db

你可能想读：

技术文档诞生记 | 完整的技术写作流程是怎样的？
Technical Writer 可提供的交付物有哪些？
Technical Writer 日常工作中好用的小工具
技术翻译需要有 Technical Writer 的 sense
深度解析关于技术翻译的六个认知误区
如何让你的内容输出更加专业更有设计感？
书单 | 有哪些技术传播从业者必知必看的书籍？
有哪些适合技术传播从业者关注的优质博客？（一）
有哪些适合技术传播从业者关注的优质博客？（二）
经验分享 | 来自 11 位 Technical Writer 前辈的职业发展建议（上篇）
经验分享 | 来自 11 位 Technical Writer 前辈的职业发展建议（下篇）
英语技术文档的标题到底该大写还是小写？
如何使用正则表达式批量添加和删除字符？
Markdown：写技术文档、个人博客和读书笔记都很好用的轻量级标记语言
如何为 Markdown 文件自动生成目录？
技术写作实例解析 | 简洁即是美
两分钟趣味解读 Technical Writer
若脱离理解，直译得再正确又有何意？
优质译文不应止于正确，还要 Well-Organized
写在入职技术型创业公司 PingCAP 一个月之后
揭秘 Technical Writer 的工作环境 | 加入 PingCAP 五个月的员工体验记

-END-