非商业转载请注明作译者、出处，并保留本文的原始链接：http://www.ituring.com.cn/article/76101
Andy Hunt是一位程序员，他还是咨询师、作者、以及出版人。他创作了很多获奖又畅销的书，其中包括《程序员修炼之道》，《程序员的思维修炼》，Programming Ruby。Andy是“敏捷联盟”17位创始人之一，他也是《敏捷宣言》的作者之一。他和Dave Thomas联合创办了Pragmatic Bookshelf出版社，他们一起用Ruby构建了整个网上业务。除了以上角色，他还是一位狂热的音乐人，以及兼职木工艺家。他创建了一个叫做memes的独立乐队。
图灵社区：作为一位演讲专家，您能和我们分享一些演讲经验吗？有很多专家级的程序员都无法完成一次成功的演讲，你是怎么实现既有趣又有信息量的演讲的？
AH: 一次好的演讲的关键其实和一本好书的关键完全相同：重点应该在于听众，而非演讲者。没错，你可能知道很多东西，而且还是个专家，但是听众并不需要知道每个细节，甚至也不需要知道所有你感兴趣的部分。他们想听的是他们感兴趣的事儿。甚至他们也并不需要你讲的是完完全全的事实，这些东西他们自己就可以在网上找到。他们想知道的是你的经历，什么真的管用，什么又不行。你的观点是什么？你对这个主题有多少亲力亲为的发现？这就是大伙儿想知道的事儿。
图灵社区：自出版现在越来越流行了，很多人开始在LeanPub或类似网站上写书。你认为传统出版在未来还有机会吗？
AH: 我认为机会很多。传统出版能提供给我们两个非常重要的功能。首先，专业级别的开发编辑和生产制作环节。我们的作者中有不少一开始就尝试了自出版，然后他们才找到我们。他们意识到一个好的专业编辑能给他们带来多大的不同——他们可以帮助你把你想传达的信息更清晰、更简练地表述出来。而且，不要低估生产制作环节：很多人告诉我们，我们的电子书看起来比别家出版社好太多。你能用工具制作电子书并不意味着你能做出一本像样的电子书。
其次，我们还是管理员，我们会剔掉那些不怎么样的书，推广那些优秀的书。读者们知道他们可以信任我们，也信任我们对于选题的选择。这些事情很难由自己一个人发展出来。但是我们已经从事出版十多年了，而且我们在自己的职业生涯中都是真正的软件开发者。我们很清楚自己在干什么。
我们最大的优势就是我们编辑，我们流线型的工作流程，我们从发布到印制之间的速度，我们的直接发行系统和遍布世界的零售渠道，我们先进的“抢先阅读(beta-book)”计划，以及我们满世界的优秀读者。
图灵社区：作为一个技术出版人，你怎么发现和跟进你的下一本书？
AH: 有很多方法；有时候作者找到我们说他们有个自认为很棒的想法。有时候我们会遇到一个选题，虽然看起来很有趣，但是仍处在项目发展早期，然后我们就会跟进这个选题然后马上确定一本书。当这个选题变得越来越流行之后，我们已经准备就绪了。
很多时候我们出版了关于某个主题的第一批书，然后这个主题变得很流行，比如Ruby on Rails。有时候我们出版了一本概念很好的书，但是大众并没有接受，比如Naked Objects。而且我们现在又有了这样的新书，它们还处在无法细说的初级阶段，比如我们的新书《Elixir编程语言（Programming Elixir）》。
有些时候我们对一个技术专题的热情和推广让它变得流行起来，被人接受。
我们在[email protected]这个邮箱里会收到很多不请自来的申请。很遗憾，我们必须得把它们中的大部分拒掉，要么是因为我们对这个主题不感兴趣，要么是展示的风格和我们大相径庭。凡是我们接受的读者，我们就会派给他一位开发编辑，这位编辑会在随后几个月的时间内和作者密切合作，为这本书的最终审阅做好准备。
对于代码，为了避免浅显的bug，我们有好几轮的内审，同时还有严厉的外部技术审读。这个过程对于作者来说可能是有些严苛，但是这样做为我们带来了真正精彩的书。
我们有一些作者在写书上得心应手，他们还会回来继续写——比如Venkat Subramaniam，他是《Java函数式编程（Functional Programming in Java）》的作者，这是他在我们这儿写的第六本书。Maik Schmidt是另外一位系列书作者，他最开始写的是《Ruby and Rails企业软件开发（Enterprise Recipes with Ruby and Rails）》，然后他又创作了一些关于Arduino和Raspberry Pi的书。
从这里我们可以看出什么才是最重要的：作者的热情。如果一个作者对于一个主题充满热情又有充足的知识，还愿意和别人分享他这份热情，那么我们就会对这个选题感兴趣。
图灵社区：你和Dave Thomas（Pragmatic Bookshelf创始人之一）都是“敏捷宣言”的最初签订者。有些签署人现在仍然活跃在软件开发领域（如Martin Fowler），有些人则开发了自己的敏捷方法（如Sutherland）。你认为现在自己在敏捷领域内的角色是什么？
AH: 我觉得Dave和我在敏捷上都有点变得愤世嫉俗。Dave认为我们应该让“敏捷”这个词退休，或者把这个词彻底收回来。最大的问题在于只有很少的团队真正在使用敏捷方法开发。很多团队采用了几种“敏捷”的方法，并从中得到一些益处，但是这和真正的敏捷实践相差甚远。有一个很危险的误解，有人认为“遵从敏捷方法”或者“做敏捷”是和真正的敏捷是一样的事儿。事实远非如此。这就像是你能给自己系鞋带和成为奥林匹克短跑选手之间的区别。如果你能在乐器上弹音阶，这当然好，但是你不一定能卖出百万销量的专辑或者能在世界上伟大的音乐厅演出。遵从已经发表的敏捷方法和在你的跑鞋上绑鞋带是一回事儿，这是个不错的开始，你也必须这么做，但这并不是比赛本身。
所以我现在的角色在于时不时地刺激一下所有人，他们没有抓住要领，需要学习的还有很多，这样的举动出于我的良心；我们软件工业仍然处于萌芽阶段，还有大把的机会。
图灵社区：计算机和信息技术在中国是一个蓬勃发展的工业。对编程新人你有什么建议？有没有什么在学习过程中不容错过的东西？
AH: 我认为应该学习这门技术的整个链条，包括从基本的三极管和电路到操作系统和编译器，以及数据库和GUIs（如今更重要的是浏览器，但不要忘了iPhones/iPads上的Cocoa，以及Qt等等。）你需要知道这些底层原件整体怎么工作，因为技术的细节每隔几年都会发生变化。要想抢在表面的变化之前，就要更好地理解整个基础。
图灵社区：在中国，由于文化环境和健康原因，40岁以上的老程序员并不多。你对他们有什么建议？你在编程中获得最多的是什么？
AH: 永远都要去学新的东西。永远。我最近有点松懈了，这个过失已经开始回来折磨我了。无论你是刚刚涉足一个新的函数编程语言（我真心推荐Elixir），或是刚刚发现一些不同风格的计算（也许是即将到来的Wolfram语言？），亦或是在Arduino或Raspberry
Pi上面做试验，你需要一直处于学习状态。哪怕最后你用不上这门技术，你学到的每样东西都在告诉你一些其他方向的知识和建议，所以没有任何学习是白费的。
图灵社区：你如何平衡你的各种爱好，编程，音乐，还有木工？如何分配时间？
AH: 很困难 ;) 我认为最好的方法就是要在一块时间内有意地让自己专注在一个单独的任务上。如果我要摆弄代码，我下个小时就会只干这个——不查邮件，不接电话，不刷twitter。如果我想吹小号或者玩合成器，同样，下个小时我就只有这个。做什么事情都要认真；要故意为之。如果我要回邮件，就像是我现在这样，那就只回邮件。
完成多重任务的关键就在于不要一心多用。一次一件事，把每件事做好。
图灵社区： Dave Thomas认为程序员相对于普通人来说更可能会成为音乐人。你认为作曲和编程有什么相似之处？他们之间有相互影响吗？
AH: 编程和音乐之间似乎有很高的关联系数。我不太清楚为什么会这样，哪个是因，哪个是果，但是这样的组合似乎确实很常见。
编程和作曲都是充满创造力的行为，或者说这两者都是一种建造世界的形式。这可能正是因为我们喜欢建造属于自己的世界，或是想要创造一个我们内在想象力在现实世界的宣言。可能我们就是喜欢鼓捣我们创造出的东西。
图灵社区：你在编程的时候听音乐吗？如果听的话，你认为什么样的音乐有助于提高编程效率？
AH: 根据任务不同我会听完全不同的音乐。比如当我正在写书或者写一个演讲的时候，我需要Steely Dan。我写代码的时候，我可能更倾向于前卫摇滚（Porcupine Tree 或经典的 Pink Floyd 或者 Yes）或者主流爵士乐，也许是Miles Davis或者Stan Kenton风格的大乐队。
我发现当我需要聚精会神的时候，不能听不熟悉的音乐——这太令人分心了。越需要精力集中的时候，我就越需要熟悉的专辑，有时候我会毫无意识地跟着哼唱起来，自然而然。
更多精彩，加入图灵访谈微信！
