Dave Thomas：一个开发者的为与不为

Dave Thomas是一位程序员，同时也是一位作者和出版人。他和Andy Hunt一起开办了出版公司The Pragmatic Bookshelf，他们整个线上业务都是他和Andy用Ruby创建的。他的个人作品包括《Web开发敏捷之道》、《Programming Ruby》。他和Andy共同写作了《程序员修炼之道》，这本书也是The Pragmatic Bookshelf品牌下的第一本书。作为一位开发者，他充满了热情，他相信这是个属于勇敢者的时代。对于业界存在的问题，他痛心疾首，并不断寻求着解决方法。作为一位出版人，他务实、精明，时刻为自己的作者着想，也为像他一样的开发者搜罗好书。他是一位不折不扣的Pragmatic Programmer。

你用Ruby干什么？你是如何参与Ruby社区的？

Dave：在过去的8年中，我用Ruby做所有的事！我们整个的线上业务都是用Ruby写的。如果你成为我们的作者，我们用来形成一本书的软件也是用Ruby写的。所以可以说Ruby就是我们公司的全部。另外，我几乎每天都会写Ruby脚本，这是我生活的一大享受。我的记性很差，如果我生活中能找到任何可以自动化的步骤，我一定会把它自动化，这样我的生活就会更加简单。

在开始的时候Ruby社区人很少，第一次聚会的时候大概只有30人。所以参与这么小的社区其实只是和朋友打交道而已。说到开源社区的贡献，我大概写了有4、5千行代码，有一些文档，也提交了一些补丁。另外，我经常参与Ruby大会，并且乐在其中。

你对其他Rubyist有什么建议？你对对Ruby这门语言感兴趣的人有什么建议？

Dave：好问题！我最大的建议就是参与进来。这就意味着找到一个你需要做的事，每个人都可以做到，不是非要是个编程大牛才可以。只要找到一个小bug或者你使用的库没有做你希望的事情，那你就可以做一个新版本出来，或者把补丁发给作者。如果有一些功能完全不存在，那么不要只是做出来给自己用，打个包发布给大家。如果这么做的话，你就是社区的一员了。这种回馈不仅会让你感觉很好，也会帮助其他人。同样，这么做也会帮到你自己，因为你有了名誉和声望，你在社区中也有了自己的位置。

你是怎么成功地作为程序员、作者、出版者工作的？这些东西占据的比例是怎么样的？

Dave：我睡得不多（笑）。作为一个出版人，我的团队非常出色。首先，我们都要感谢自动化，我们可能是世界上自动化程度最高的出版公司。我们整个公司没有一张电子表，这些都要归功于Ruby。比如我知道很多出版商如果要发布一本书的新版本的话，需要在之前工作一两天的时间，而我们只需要……大概5秒钟。自动化是关键点之一，通过高度自动化，我就有了更多空余时间。另外有很多杰出的人才和我们一起工作，他们工作得比我好。我很幸运，他们可以帮我完成很多工作，所以我有时间空余出来。虽然有一些我必须做的事，但是大部分时间我可以做我喜欢做的。也就是去了解新的科技，和有趣的人交谈，继续探索，说实话……这种生活真的很享受！

我们没有办公室，每个人都在家工作。所以我早上起床之后，查查邮件，遛遛狗，回来再做事……所有事都是生活的一部分，所以我不用把我的时间分割成8小时工作和下班。其实我每天的工作时间多于8小时，但是事情都是分布在各种时间段里，所以感觉起来不像是在工作。当天气晴好的时候，我可以坐在外面边晒太阳，边打字，这样的感觉很好。

作为一个出版人，你怎么策划出下一个选题？

Dave：有两个问题，第一个是需要知道接下来什么才是最有趣的技术；第二个是找到合适的了解这门技术的人来写作。

要想知道什么技术会大放异彩的关键就是要和正确的人对话。我有一条原则，如果我在一个礼拜内听到某种新技术两次，那这种技术就会进入我的候选名单中。每周我们都会召集我们所有的编辑开一次会，我们在会上会讨论这些话题。这时候可能就会有某个编辑说，嘿，刚巧我认识一个这方面的人。否则，我们就得出去找人了。这可真是个问题，因为知道这些技术的人还刚巧都是些大忙人，他们都在自己的项目上忙着呢。所以，为了减轻他们写书的痛苦，让他们的工作更加简化，我们提供了一些工具。如果你是一位开发者，使用这些工具是很自然的事。但无论如何，写书都是一项艰难的工作。

现在很多书都在教人如何制作自己的编程语言，操作系统，这样的DIY项目似乎也不是大牛的专利，比过去更加容易实现了，你对想做这些的程序员有什么建议吗？

Dave：每个人到了一个时期，都会看着某个项目或者技术说：我能做得比他好。这种可能确实存在，但是90%的可能是，他们做不到。因为他们没有理解到这个项目或技术后面的细节以及微妙之处。对于那些可以做到的人，很多人都花上一年的时间，根据某些已有的项目重新实现某些功能。这个项目可能会变好……5%，但我所看到的是，他们在别人的想法上花了一年的生命，而这种提升只是边边角角的。倒不如把这一年的时间花在实现自己的想法上，这样做的话你可能会失败，但是你学到的东西会多得多！如果你没有失败，那你就创造出了一种全新的东西，这是让人兴奋的。

你想做自己的编程语言吗？

如果你愿意的话，当然可以。但是现实是，这门语言很有可能不会大受欢迎。因为有很多人在这么做，而且你成功与否不仅在于技术能力，更要靠运气。如果我想贡献自己的代码的话，我不会这么做。因为从我的经验来看，我每年都会又一次坐在那里勾勒自己的语言，然后我想起来这句话：不要这么干！然后我就会放弃掉。

做自己的语言或操作系统变得更简单了吗？是也不是。可能更难了。创造这些的工具确实是更好了，我们对于技术的了解也更多了。你可以把你的语言放在JVM上。但是人们对于编程语言的期待也更高了，所以实现起来很困难。所以如果你想投入大把精力在某件事上，我不建议你去发明一种语言，这样做的风险很高。

作为一个出版者，你对于这些自建项目的书也不感兴趣吧？

Dave：我们每个礼拜大概都会收到两个这样的提案。他们会说我们做了一种全新的语言或者框架，关于这个项目我想写一本书。我们管这些书叫做“我充实的暑假”。一门受欢迎的语言至少需要你花半个月的时间把它发布出来，然后需要至少有50-100个积极参与者。一门语言至少需要这些启动力，才有可能变得被大众接受。如果只有你和你的爱犬喜欢这个项目，那你就还差得很多。为这样的项目写书，不会让它变得更好，只会浪费你又一年的时间。美国有一句谚语叫做：“good money after bad”（陪了夫人又折兵）。所以我们一般不会做个人项目的选题，这样对于出版社和作者都是一种伤害，尤其是对作者。

Ruby和移动开发结合比较热门，松本行弘本人也专注去做mruby了。请问对Ruby与移动开发的前景有什么看法，需要逾越那些障碍？

Dave：对于移动方面的开发最大的挑战就是没人知道怎么去做。但是没关系，因为我们在不断努力尝试，犯错误，然后从中学习。我认为移动不是重要的，而是唯一至关重要的开发。它并不只是手机，而是分布网络下的各种东西。人们讨论的因特网一样的连接，我认为这种实现的到来会比我们期待的更快。所以我们要找到一种编写系统的办法，这种办法可以支持成千上万处理器，它们出现在各种地方，进进出出，然后把他们整合到一起，在需要的时候还可以拆分开来。比如当我走入一个房间，然后我的手机，或者设备就开始和这个房间对话，它会告诉我需要知道的信息。我认为这将在不远的未来就可以实现。

在这样的未来中，Ruby的领域在哪里呢？

松本在做mruby，这是一种模块化设计语言，所以你可以选择你需要的功能。你可以选择运行，或者把它变得更加轻量。我昨天和他通话时谈到了mruby，他说有一家公司在使用mruby做他们的渲染器，他们把它设置成有45kb的内存印迹，这真是难以置信。这就是Ruby应该发展的领域吗？我不确定。Ruby最开始应用的领域是比刚才所说的退一步的地方，也就是设备之间的接口。所有设备只是骨架上的皮肉。回归这样的位置也许更好，我希望Ruby可以从一种杰出的Web开发语言的定位上移开。它并不只是一种Web开发语言，不能因为rails很红就说它只属于Web开发。Ruby并没有改变！它只是用来写Web应用很顺手而已。我觉得Web应用在未来可能会降温，所以我也希望Ruby可以回归本源，并且与时俱进。

pragprog.com前段时间出版了ruby motion的电子书，之后是否有更多类似题材的选题可以先透露一下。

Dave：还有很多。我们其实很自私，我们只出版自己感兴趣的书！对于和我们所做的其他事相关的话题一般都很感兴趣。ruby motion很有趣，我也想出一本mruby的书。我们不仅关注语言，也很关注语言的不同用法。我们这方面的书还不够多，我很期待有人能够提供Ruby，Erlang等等这些语言的成功用例。这些话题总是很有意思。

你从事开放出版很长时间了，你能介绍一下你的经验，和开放出版在当下的现状吗？

Dave：我们写书的方式和其他出版商不同。大部分出版社会对作者说，第一章应该在3个月内完成，第二、第三、第四章要在……所以作者们写完一章就继续写下一章。这样真是荒缪极了。根据我们的经验，当你写书时（尤其是第一次写书时），你其实不知道书的整体结构会是怎么样的。所以你经常会写下一些东西，然后发现它不应该出现在现在的位置上。所以我们不会一章一章的写作，而是让作者把主要内容写出来，然后我们的编辑会和作者一起来为书梳理架构。所以我们不会说“这是本书的前五章”，我们会说“这是本书50%或60%的内容，也许真实出版后的顺序会大不一样，但这些都是书中的内容”。所以当一本书达到50-60%的时候，编辑同意的话我们就会把这本书发布出来作为一本beta书。从我的观点来看，这是很容易做到的，只要按下发布按钮就可以了。之所以我们需要编辑同意，是因为通常我们会期待这本书每两三个月就有一次更新，在书出版之前，作者还有更多内容要放进来。

这样做的好处就是，首先从读者来说，先拿到一本技术书是很重要的，如果这本书足够有趣，就可以先睹为快。从作者来说，突然之间，收到上千条的反馈是很有意义的。大部分反馈可能都是一些小问题，但是曾经有几次，有人明确指出了书中的一些错误，那么作者就需要重新写这个部分。这其实就是我们想要的。这样做也让这本书吸引到了更多的人。当新版本形成时，编辑们会更新改动日志，然后告知大家新版本已经发布。现在甚至更近了一步，我们有几本书，它们永远处于持续更新状态。作者同意，这本书会持续两年不断更新，我们也会在网站上跟进。我们不会用传统印刷方法（传统方法意味着每次更新都要印3000册书），我们会采取“按需印刷”的方式。读者可以说我要这本书现在这个状态的纸质版，然后我们就会印出来发给他。这种方式真的很受欢迎，唯一的问题就是很难找到能和我们这样合作的作者。这样做对于作者来说是有很大回报的，书的销量会有很大上涨。这样书的内容既新鲜，寿命也更长久。人们总会为这样的书蜂拥而至。如果一本书一出来就已经过时了的话，人们就不会再买了。

图灵社区：听起来很不错，这更像是一种产品，而不是一本书。

Dave：你说得很对，这更像是一个软件产品。

图灵社区：在美国还有别家出版社也在这么做吗？

Dave：有的。Manning有“先睹为快计划”，O'Reilly好像也有类似的项目。要知道，好主意总是被模仿嘛！

翻译版的技术书籍上市时间一般要晚于原版一年甚至更久。在出版流程的合作方面，可以在beta阶段就由翻译方介入，加快中文图书的上市速度吗？是否考虑与中文翻译方（图灵）是否有这方面的讨论和进展？

Dave：这个问题我们每个礼拜都要被问到。就像上面所说的，我们的根本问题在于我们的书不是按章写成的。如果我们给你们一本书，其中有50%的内容尚未完成，那么一个月后，我再给你们一个新的版本，现在有60%未完成。但是第一章的一半被挪到了第七章，第三章被删除了，第四章和第二章合并了，而且我们打算给这种技术换个名字……如果你们拿到这样的书，译者可能会出门右转，了却此生。如果你们愿意尝试的话，我们可以一起试验，看这样的方式会怎么样。对于我们来说这样做很简单，但是我们不想为别人制造痛苦。另外还有一个原因就是，我们从未卖过一本还没有完成的书，我个人不喜欢销售还没有完成的作品，但是这样做并非完全没有可能。这也就是从我们系统上只能买到已经正式出版的书籍的版权的原因。我的担忧是，这么做有可能会得不偿失。但是如果有人想接受这样的风险，我们也可以共同来尝试。

现代计算机领域的发展真的像某些“专家”说的那样不可能是个人创造历史的时代了吗？大家只能依附于大公司的团队吗？

Dave：我觉得这些专家真是错得一塌糊涂。我认为个人才是创造历史的源泉。而大公司只是跟风而至，创造金钱而已。听起来有点愤世嫉俗，但是事实就是，只有个人才有那种勇气和自由来不断实验和犯错。你必须是一个有勇气的人。

如果你从事的是硬件领域的工作，制药、制造这些，当然，你需要一个大公司，你需要价值百万的设备来从事你的工作。但是如果你身处软件行业，你需要什么？一台电脑，足矣！你站在很多巨人的肩膀上，比如Linux, Microsoft，你有用来编译各种语言的免费编译器，你有免费的数据库，你有成功所需要的一切！也许最终确实需要一个团队来把事情做得更好，但是在开始的一两年中，你自己就可以完成伟大的事。事实上我认为，作为个人，成功的几率要比大公司高得多。

你需要亲身体会风险的感觉，你处在前沿，同时你也处在失败的边缘。如果你是事务缠身的商务人士，我很难想象你会进入这样的状态。

很多公司在招募新人的时候倾向于找具有技术广度的人，但是作为程序员可能在某一阶段对深入的研究某些技术感兴趣，对于深度和广度，你认为在什么时间点做这样的抉择比较合适呢？

Dave：我的经验恰恰相反，我认为大多数公司在招人的时候并不看重知识面宽广与否。他们有很多坑，他们只想找到能够填充到那个坑里的萝卜就好了。他们招人的要求非常具体，程序员面试的时候会做一些编程测验，只要他们能做这份工作就可以了。他们填完这个坑，就开始盘算填下个坑。如果你是一位程序员，你想被一般的破公司雇佣，那你只要看看他们的要求，然后把你的经验填进去就可以了。这真是惨绝人寰。

有两种程序员，一种人把编程当作工作，一种糊口的手艺。他们早上上班，然后编程，然后下班。他们在工作之余从不想关于编程的任何事，他们不看相关书籍，也不会和朋友们聊到这些事，这只是一份工作而已。对于这些人，他们在坑里也很开心。但是如果你所说的是优秀的程序员，那他们想都不该想跳到这些坑里去。他们在这样的环境下会窒息。他们需要的是找到那些不根据那些条条框框招人的公司。这样的公司需要的是“聪明人”，可以沟通的人，有激情的人。这也是我们的目标读者，这也是我想要雇佣的人。

我可能是世界上最差的雇主，我招来的人要么就是完美的，要么就是一场灾难。我看人最重要的一点始终是热情。我招的人可能只有一半接受过正式的计算机相关教育，其他的人都是自学的。但是这些自学的人基本上都是更优秀的开发者。

如果你的工作和事业是软件开发，你的热情也在于软件开发。那你就必须要不断学习。如果你不持续学习的话，你就会过时，你的技巧会没有用武之地，你也体会不到乐趣。作为程序员，你应该始终领先于潮流一点点。如果大家都在看Java，你应该学Ruby，如果大家都在学Ruby，你应该看Scala或者Elixir，或者其他什么。有的人会说，我上班的时候太忙，没有时间。我要说，这不是你的工作，这是你的事业，这是你的生活。

现代编程提倡让他人理解最重要，斯坦福大学的老师甚至说注释和代码一样重要。冗长的注释会不会让代码的简洁性大打折扣？

Dave：我不太同样这种说法。我认为注释会让代码更不容易理解。我认为注释是一个借口，为了你表意不明的代码找的借口。如果你认为你的代码很复杂，或者有些问题没写清楚，那你就会想为你的代码写一段注释。别这么做！你的代码有问题，解决代码的问题先，让它变得清晰、易懂。如果某家公司有一个编程标准，说程序员必须为代码写上大把的注释。快停下来吧！这都是些不相干的事。程序员的产出应该是商业价值，注释并没有增加任何商业价值。我用注释吗？我确实用，但是极少。基本上，我都是在自己没有能力把代码变得更好的情况下才写注释。对于我来说，注释是一个“这段代码有问题”的信号。

您觉得数学和编程的关系怎么样？最近Google大牛Steve Yegge觉得数学很重要，您觉得两者关系大吗？

Dave：我不认为数学是必学的功课。但是我承认，有一些人的思维和软件开发的思路很契合，这种思维追寻模式，寻找事物之间的联系，能把各种各样的东西结合在一起。这可能也是数学家们的思维方式。但是我知道很多音乐家也能够做到这些。如果有一屋子的程序员，你问问他们谁会演奏乐器，你的结果差不多应该是30-40%。我不知道对于一般人来说，这样的比例是多少，但是应该达不到这么高。程序员们演奏起乐器来可能比普通人更擅长。我的朋友Chad Fowler（《Ruby编程（第2版）》合著者之一）原来是一位职业萨克斯表演者，他曾经在田纳西的孟菲斯乐团演奏。我的合作伙伴Andy是一位爵士鼓表演者。我认识的很多人都会表演乐器。可能有些人的大脑和思维方式更适合做这些事。

程序员可能会擅长于数学，或擅长于音乐，但是我不认为必须要有很深的数学功底，才能成为一位开发者。

图灵社区：我在您的网站上看到了您写的音乐。

Dave：是，我是作了一些曲子，但是我的问题是我不会表演。演奏我曲子的是另一位程序员，现在他正在一个和爵士乐相关的开源项目上。我们共同创作了这首7分钟长的曲子。

听说您对中国的教育事业很感兴趣，是真的吗？

Dave：我对中国的两件事很感兴趣，不不，其实是很多事（笑）。 第一件事软件开发，我去过世界很多地方，也见过世界各地的程序员。每个地方做事情的方式都不一样，这种区别通常以国家为界。我想理解每个国家的文化是如何影响当地的软件开发过程的。这只是我的一个爱好。比如说在日本，那里的文化要求所有人的意见都能统一，甚至是无法统一的情况。所以和那里的程序员交流挺没意思的。他们只能看到需要他们来修补的东西，他们必须是团队的一员。这是不对的，这样的做的结果就是整个的开发流程也会因地制宜，受到影响。我也想了解中国的程序员是如何工作的，但是现在我还没有掌握足够的信息。

至少在美国，在大公司上班的程序员很多都有自己的项目。他们在公司上班的状态也是不固定的，他们经常上一阵班，然后再赋闲在家开发一段时间。我觉得这样的混合经历会让他们可以经常换换脑筋。我感觉中国的情况可能不是这样，但是我不确定，我还需要和更多的人交流。

另外一件事就是教育。在美国，软件开发在学生中间不是很受欢迎的专业。在大学学计算机相关专业的学生在减少。我认为这是一场危机。因为这就意味着我们讲没有足够的人才，我们有可能会落后于世界。这在美国是一个问题，所以我一直都想办法让美国的青少年对软件开发更感兴趣。我一直在尝试，但是始终没有找到好的方法。在美国，女性程序员的比例小于20%，在其他职业中的比例小于50%。我希望这个状况可以改善，至少可以增加开发者的整体人数。这件事的意义当然不止于此，我不知道造成这样结果的原因是什么。是遗传生理上的差异，还是现有软件社区很丑陋，排斥女性加入。我知道中国的情况可能还不如美国。不知道这样的情况通过让青少年增加接触编程的机会能否有所改善。对于有些人来说，软件会是一件很有趣的事，毕竟这是为数不多的凭借单枪匹马就可以改变世界的事。你可以改变现实，通过打字，就能够创造一片天地。如果我们能把这样的思想传递出去，也许就会有越来越多的人来学习编程了。这就意味着我们必须要实现承诺，让公司们明白，软件不是填坑就可以了，要让程序员们有空间发挥自己的热情，创造出更杰出的产品。

从这个意义上讲我确实对教育很感兴趣。比如说在美国有一个项目，让无业和穷苦的人们接受教育，学习新技能。软件是一个学习成本很低的技能。有的机构向贫苦的孩子们捐助电脑，帮助他们学习，这真是好事一桩。让每个人都有机会接触电脑，不只是玩游戏，而是亲手创造一些什么。

听说您正在写一本关于用Elixir编程的书，能告诉我们Elixir最吸引你的地方是什么吗？

Dave：因为我喜欢！这其实就是最根本的原因。Elixir能让我微笑，所以我愿意和别人分享这样的快乐。对于Ruby来说也是这样，我想和别人分享这份愉悦。

从另一个层次说，软件世界在发生变化。每隔两年，计算机的数量就会翻一番。为了适应时代，我们必须改变计算机工作的方式。在过去，我们做的就是让计算机变得更快。现在，计算机里的处理器更多了，我的笔记本是四核的，也许明年就是16核或32核的了。所以作为软件开发者，我们没有选择，我们需要写出在这些机器上运行良好的代码。这又回到移动设备上的问题，这些代码不仅要在不同的设备上运行，还要在同一设备上的不同处理器上运行。用传统编程语言，比如Java、C#或Ruby，要写出多核运作的正确代码是很困难的。Elixir是一门以Erlang为基础的语言，Erlang已经诞生了30年。这门语言的很大一个部分就是Erlang虚拟机，它可以支持数以百万计的处理器，它们以极高的效率相互通讯。它可以很有效地调控这些处理器，如果其中一个坏掉了，仍能在不影响其他处理器的情况下继续工作。它也可以改变处理器，而不需要影响到正在运行的应用。所以在电话中转中，很多软件都是用Erlang写的。启动转换之后，运行不会停止。这些都是很好的特性。但是，Erlang语言本身却十分丑陋。虽然确实有人喜欢这门语言，但它对程序员并不友好，至少可以说独树一帜到令人担忧的程度了。

Elixir是将与Ruby类似的句法，放在Erlang虚拟机上。这样既可以得到虚拟机的好处，又可以写出更加平易近人的代码。不仅如此，Elixir还可以利用虚拟机做到Erlang也做不到的事。在Elixir里什么都是可以改变的，程序员会觉得很有趣，还可以避免Erlang里的重复代码。所以你写出来的代码会更短，也更容易改变。在未来，我觉得Elixir可以用在大型分布式系统上面，它可以用在大容量，大量事务的环境中。它也可以为创业者们服务，为他们完成用传统方法无法完成的事。创业者们永远都在找从前无法实现的事，具体是什么呢？我不知道，如果我知道的话就去创业了。他们可以尝试从连接所有东西，和很多东西交互的角度来考虑（比如和洗碗机，或者洗衣机交流）。我对此充满了期待。