Dave Thomas采访英文原文

应大家的要求把Dave Thomas采访的原文发布出来，英文好的同学们可以看这篇哦，直接感受大师优美的文字和风采！！

• Since when did you start programming? What kind of fun the programming brings to you that made you so fond of it? In the process
  of self-transcendence, have you ever had any hard time, have you ever
  thought of giving up in that moment?

I first started programming in 1972. I was at high school in England.
A group of us had taken some exams early, and the school didn't know
what to do with us. There was a technical college across the road that
had just started giving classes on programming, and we asked if we
could attend there twice a week.

I was originally planning on studying mathematics at college, but when
I started programming, I slowly fell in love with it.

At the time, I was programming in Basic, entering my code onto paper
tape, and then feeding it over a 110 baud modem up to a mainframe to
run. Despite this, I found that programming really fit the way my
brain worked—I loved the fact that it was both creative and precise.

I really haven't stopped programming since then—I'm fairly sure that,
except for vacations, I've written code every day of my life since
then.

I've often had hard times, but I think that in the end they actually
help bind you closer to your craft. Anything worth doing will be
difficult, but overcoming those challenges both makes you stronger,
and also adds to your commitment.

• We are being presented to a fast changing world, and new technologies
  are emerging and existing ones are always evolving. How to catch up
  with the world and enhance his own competence, as a programmer?

That's an increasingly difficult thing to do. When I first started,
you could keep up by reading books and magazines. Now, it seems like a
new concept appears every day.

But, the reality is that many of these new things are just people
reinventing the past. Many people in our industry only look to the
future, and have very little knowledge of the history of computing.
Those people want to invent things (which is good), but they don't
know about work that was already done, often 20 or 30 years ago.

Because of this, many of the new things that come along aren't really
that new. From my point of view, that makes it easier to keep up,
because I can just look at them and say "ah, that's like X."

But there is also good new work being done. I find that maybe once or
twice a month, I come across something really interesting. When I do,
I always try to play with it. Reading about some technology is
interesting, but you have to try it if you want to get a deeper
understanding.

This is a lot of work, but it is important for every developer to make
this investment. If we don't, then we make ourselves obsolete.

• The job position in big companies have been divided into small pieces, such as front-end, server side/backend, operation and
  maintenance, database admin and so on. But most programmers have been
  fixed to a specific position. What’s your opinion on improving the
  width and depth of tecnology?

Specialization is for insects. The people who are really making a
difference are the people who can add value by combining technologies,
and who have a broad range of abilities.

I agree that many companies don't recognize this. They feel more
comfortable creating hierarchies and slotting people into roles.

But there are companies that are different. They understand that they
get the best out of developers by giving them objectives and guidance,
but not dictating the details. They understand that a good developer
can also handle database schemas, plan deployments, and probably will
enjoy helping out with support issues.

I would encourage every young developer to get experience by moving
around between companies for a while. Get to see the differences, and
find out which styles work for you. Try large companies, and try
startups. Maybe even try working independently. Once you know what you
want, then work to find or create a position where you can do your
best.

It is easy when you are an employee to blame your company, to have an
attitude like "I'm just one person—I can't change things." But the
reality is that you actually have a duty to change things—to make them
better. That duty is to your company, but also to yourself. See if you
can get your company to change. And, if they won't, find yourself
somewhere different that's closer to what you need.

• The Pragmatic Programmer has influenced many programmer, if you want to republish the book, what kind of change will you make?
  Today, how to be a pragmatic programmer?

Andy Hunt and I talk about this every now and then. The reality is
that, although the technology examples in the book are looking a
little old, the underlying concepts are still pretty applicable. It
doesn't matter if you're coding in C++ or Javascript, the DRY
principle still applies :)

There are a few tips I would personally change or remove, but nothing
major.

How to be a pragmatic programmer: do what works, and work at what to
do. The "do what works" part means you should always be asking "what
is the value of what I'm doing?" and trying to find ways of improving
the value you get out of each day. The "work at what to do" parts
means you should step back and looking at the big picture, and find
new and better ways of working.

• As a technical guru running your own company, how do you think of the entrepreneurship regrading a programmer? What are the
  strengths and weaknesses of a programmer who wants to set up his
  own business?

That's a great question, and one I don't really know the answer to.

I know one weakness I have it that I like things to be simple—I think
most programmers value simplicity. But the real world—the world in
which our company operates—is not simple. I have to fight my natural
temptation to over-simplify things, because I know I miss
opportunities when I do that.

I think a major strength of developers as business people is that we
understand how things interact. We can use the same principles that we
use to organize our code to organize the way our companies run. I
think this is one of the reasons The Pragmatic Bookshelf is
successful. When we started, we had no idea what book publishers did,
so we just organized ourselves as a software company that happens to
produce books, not code. As a result, we have things such as version
control, continuous build systems, and total automation for all
aspects of out business. I don't think any other publisher can do
this—our ignorance of the publishing industry was actually a major
strength.

• In RubyConf China, you have mentioned a new programming language Elixir, why it attracted you? Will you promote it as you did for
  Ruby? Will it be the trend in the near future?

I firmly believe that the future is concurrent and distributed. The
idea of writing a program that starts at the top and finishes at the
bottom will seem laughable in five years.

But, at the same time, we really don't have the tools that will let us
create distributed, concurrent systems. Writing concurrent code in
Ruby or Java is error prone. Writing it in Javascript is equally
painful.

The Erlang language has been around for 25 years. Erlang was designed
to be distributed and concurrent. It was designed for large-scale, and
reliability—environments where the code just has to keep running (even
while it is being updated). The problem is that Erlang is pretty
arcane.

That's where Elixir comes in. It is a language that looks a lot like
Ruby—it is easy to understand and to write. But it runs on the Erlang
virtual machine, and that means it gets all the benefits of Erlang.
But is can also do things that Erlang cannot do—it has very powerful
metaprogramming, macros, protocols, and so on.

Will Elixir take over the world? Probably not. But I think it points
the way to the future. So I view learning Elixir as a way of teaching
myself to understand then way I will be coding in the future. Five
years from now, I may not be programming Elixir, but I'm convinced I
will be programming something similar, and the lessons I learn with
Elixir will help me.

Maybe this sounds like I think Elixir won't make it. That's not the
way I feel. Right now, I think Elixir is one of the best languages and
runtimes that we have. When I'm not working on existing systems (which
are in Ruby), I'm coding in Elixir, and I'm loving it.

I encourage other developers to try Elixir (or something similar),
simply because I always encourage developers to learn.

• In the age of mobile internet, is there anything changes in the patterns of mobile related product development comparing to the web
  page?

I think it's going to be a significantly different world for
developers five years from now. The browser is basically the same as
the old 3270 that IBM had hooked up to mainframes—you send it data,
the user types something, and then it sends a response. The server is
in charge. I know that we're adding more and more front-end smarts in
terms of Javascript apps in the client, but the overall architecture
remains the same. And I think the browser is basically a dead-end
technology. I look at the people around me—they are using apps on
phones and tablets. They'll use a browser if they have to, but the
mobile world is user-centric, not server centric.

In a mobile app, the client is in charge, and the servers are simply
resources it uses. This requires a new set of skills from developers,
and a new set of technologies to support them. On the client side, we
need a way of writing these complex, asynchronous applications that
will run across a range of different devices (and not just phones or
tablets). And on the server side, we need to move away from the
Rails-style application into an architecture that is more federated
and flexible. (And that's one of the reasons that Elixir is exciting).

• Last year in the QCon China, you spoke about the corruption of Agile and what Agile really is. Is there any industry/area that
  Agile is not suited for?

Your question assumes that "Agile" is something.

Here's the truth. Agile doesn't exist. It isn't a "thing", a noun.
People have started using it that way, but they don't understand the
underlying meaning.

Agile isn't a thing. Agile is an adjective—it describes a thing. So
you may have an agile team, or an agile process, but you are never
Agile.

What does this mean? It means that the people who push something
called Agile are lying to you. They can't sell you "Agile".

Instead, agility starts with people—individuals who want to do
something well. These individuals look at how they do things, and
looks for ways to improve them. Kent Beck says that this requires
courage, and he's right. Every time you try to make improvements,
you're trying to change the status quo. You are taking a risk. You are
challenging the people you work with. And they will challenge you
back.

But, to answer your question, I cannot imagine any situation in which
those challenges and the resulting discussions would not be suitable.

• Have you ever being familiar with the programmers in China? What's the differenences between the Chinese programmer and the programmer
  in western country?

One of the reasons I love visiting China is having the opportunity to
talk with the developers there.

On this trip, we had a great time at the incubator cafe (whose name I
have forgotten). My wife and I were totally blown away by the energy
and enthusiasm. In fact my wife was so impressed she blogged about
it:http://myasiafix.weebly.com/1/post/2013/10/the-future.html

Programmers in the west can also have this kind of enthusiasm. But the
ones I meet in China seem to have something more. Maybe it is because
they are working in more difficult conditions. Maybe its because the
Chinese market is only just starting to explode. But I always feel
more energy in China.

At the same time, there's another side to the picture. Something I've
noticed talking to some Chinese developers is that they are working
because they feel it is their duty. Perhaps their family has pushed
them into software because it is a "good" career. Or perhaps they are
seeking the safety of a large organization. Whatever the reason, many
of these developers seem to lack a passion, a love for what they do.
And this is sad, because software can be so rewarding and so
satisfying. So I'd ask those developers to look at the pictures in my
wife's blog post and ask themselves, would they like to be there.
Would they like to be showing off their new ideas to someone across a
table?

They could do it—everyone can.

---

技术人攻略访谈是关于技术人生活和成长的系列访问，欢迎和我们有共同价值观的你关注“技术人攻略”，邮箱 [e-mail]，新浪微博 @devlevelup，希望能成为技术人成长的精神家园。
欢迎通过微信公众账号关注技术人攻略