[英]Andy Hunt：音樂和程式設計，都是想象力在現實世界的宣言（圖靈訪談）

Andy Hunt是一位程式設計師，他還是諮詢師、作者、以及出版人。他創作了很多獲獎又暢銷的書，其中包括《程式設計師修煉之道》，《程式設計師的思維修煉》，Programming Ruby。Andy是“敏捷聯盟”17位創始人之一，他也是《敏捷宣言》的作者之一。他和Dave Thomas聯合創辦了Pragmatic Bookshelf出版社，他們一起用Ruby構建了整個網上業務。除了以上角色，他還是一位狂熱的音樂人，以及兼職木工藝家。他建立了一個叫做memes的獨立樂隊。

iTuring: As a proficient speaker, would you please share some experiences with us? There are lots of expert level programmers who could not deliver a successful presentation, how do you manage to make an interesting and informative presentation?

The key to a great presentation is really the same thing as the key to a great book: the focus needs to be on the audience, not the speaker. Yes, you may know a lot of material and be an expert, but the audience doesn't need to hear every little detail, or even all the stuff that you are interested in. They need to hear the stuff theyare interested in. And they don't really want facts, that much. That's the stuff you can look up online. They want to know about your experience: what actually works, and what doesn't. What are your insights? What have you personally discovered about this topic? That's what folks want to hear.

iTuring: Self-publishing is getting more and more popular, many people choose to write on LeanPub or similar websites. Do you think traditional publishing still has its chance in the future?

Oh very much so. Traditional publishing offers two very important features. First, professional level development editors and production. Quite a few of our authors actually self-published first, and then came to us. They realized what a difference a good professional editor can make—how they can help you express your message more clearly and concisely. And don't discount production: folks tell us how much better our epubs look compared to epubs from other publishers. Just because you can make an epub with a tool doesn't necessarily mean you can make it look good.

Second, we act as curators, culling out the mediocre books and promoting the excellent ones. Readers know they can trust us, and trust our choice in titles. That's a hard thing to develop out on your own. But we've been in publishing for over a decade, and we've been software developers all our professional lives. So we know what we're doing.

iTuring: Pragmatic Bookshelf is one of the most innovative traditional publishers. What are the biggest advantages of Pragmatic Bookshelf comparing to self-publishing?

Our editors, our streamlined workflow, how quickly we can release and get into print, our distribution both direct and through retail channels worldwide, our pioneering beta-book program, and our outstanding readers all over the world.

iTuring: As a technology publisher, how do you find and pursue your next title?

A variety of different ways; sometimes authors come to us with an idea that they are passionate about. Sometimes we come across a topic that looks very interesting, but is very early in its lifetime, so we'll follow it and get a title started right away. Then when the topic becomes more popular, we're ready.

Many times we've published the first (or one of the first) books on a subject that's gone on to become very popular, such as Ruby or Rails. Sometimes we publish a book on a great idea that doesn't get accepted, such as with Naked Objects. And we've got new ones where it's too early to tell yet, as with the new book Programming Elixir.

And sometimes, our interest and promotion in a technical topic makesit become more popular and accepted.

We receive a lot of unsolicited submissions to proposals@pragprog.com. Unfortunately we have to turn most of them down, either because the topic isn't interesting to us or the presentation is too far away from our style. The authors we do accept are assigned a development editor who then works closely with the author over the course of several months to get the book ready for reviews.

As with code, many eyes make for shallow bugs, so we have several levels of internal review as well as external tech reviewers. It can be a tough process for an author, but the result is some incredibly great books.

A few of our authors get really good at it, and come back for more—like Venkat Subramaniam, who just authored Functional Programming in Java Harnessing the Power of Java 8 Lambda Expressions, which I think is his sixth book with us. Maik Schmidt is another serial author, who started off with Enterprise Recipes with Ruby and Rails and went to write several Arduino and Raspberry Pi books.

And that's really what it's all about: the author's passion. If an author is passionate and knowledgeable about a subject, and can share that enthusiasm with others, then we're interested.

iTuring: You and Dave are the original signers of Manifesto for Agile Software Development. Some of the signers are active in the software development industry, and some of them have developed their own methodologies of Agile. How do you conceive your role now in Agile?

I think both Dave and I have become a little cynical about agile. Dave thinks we should retire the word "agile", or perhaps seize it back as our own. The problem is that very few teams are actually developing in an agile manner. Many teams have adopted a few "agile" practices, and are seeing some benefits from that, but that's a far cry from become a truly agile practitioner. There's a popular and dangerous misconception that "following agile practices" or "doing agile" is the same thing as "being agile." It is not. It is not even close. The fact that you can tie your shoes doesn't make you an Olympic sprinter. If you can play a scale on a musical instrument, that's great, but you won't sell millions of records or play in the great concert halls of the world. Following published agile practices is the equivilant of tying the laces on your running shoes. It's a great start, you need to do it, but it's not the race itself.

So I see my current role as that irritating voice of conscience reminding everyone that they missed the point, and that they still have a lot of learning to do; that our industry is still embryonic, and there is a lot of opportunity out there.

iTuring: Computer and information technology is one of the most uprising and promising industries in China. Do you have some advices for programming freshmen? Is there something they ought not to neglect in their learning process?

I think it's important to learn the whole span of technology from basic transistors and circuitry to operating systems and compilers, on up to databases and GUIs (today mostly the browser, but also Cocoa on iPhones/iPads, Qt, etc.) You need to understand how all the low-level pieces work in general, because the details will change every few years. The best way to keep ahead of superficial changes is to understand the foundation well.

iTuring: There are rarely programmers over 40 in China. Most of the developers would turn managers when they are older. Some people attribute this phenomenon to bad health or incompatible culture environment. Do you have any suggestions for Chinese developers? What do you get most from your coding life?

Always learn something new. Always. I slacked off recently, and that lapse is coming back to haunt me. Whether you dabble in a new functional programming language (I heartily recommend Elixir), or explore different styles of computing (perhaps the upcoming Wolfram language?), or experiment with an Arduino or Raspberry Pi cluster, you need to always be learning. Everything you learn informs and advises every other area of endeavor, so no effort in learning is ever wasted, even if you don't end up using that particular bit of technology.

iTuring: How do you balance your different hobbies, programming, music, and carpentry? How do you divide your time?

With difficulty ;) I think the best way is to be deliberate and stay focussed on a single task for a block of time. If I'm going to twiddle some code, I'll set aside the next hour and do that -- no email, no phone calls, no checking twitter. If I'm going to play trumpet or synthesizers, same thing: take the next hour and do it. Do it like you mean to do it; do it deliberately. If I'm going to answer emails, then that's what I'm doing right now, and just that.

The key to multitasking is to notever multitask. Do one thing at a time, and do it very well.

iTuring: When Dave came to China, he said that he believed programmers were more likely to be musicians than common people. Do you see resemblance between programming and coding? How do these two influence each other?

There certainly seems to be a very high degree of correlation between programming and music. I'm not sure why that is, or which one leads to the other, but it does seem to be a very popular combination.

Both are highly creative acts, perhaps both are a form of world-building. Maybe we just like to build our own worlds, to create real-world manifestations of our own internal imaginations. Maybe we just like to tinker with own inventions.

iTuring: Do you listen to music while programming, if so, what kind of music is likely to improve programming efficiency for you?

I listen to different things depending on the task at hand. For instance, when writing a book or a talk, I need Steely Dan. For coding, perhaps progressive rock (Porcupine Tree or classic Pink Floyd or Yes) or more straight jazz, maybe some Miles Davis or Stan Kenton-style big bands.

I find it harder to listen to new or unfamiliar music when I have to concentrate—it's too distracting. The more I need to focus, the more I need a very familiar album, something that I can sing along to without having to think. It's just automatic.

---

更多精彩，加入圖靈訪談微信！