[原文在 www.yishan.cc 连载, 现在合成一篇]
我去年读了 “Coders at Work”, 对15 位顶级程序员的采访， 总共600页。 从采访的模式看，有点像“艺术人生”， 一般都是音乐起，讲小时候的故事，你怎么开始写程序的? (Brad 同学 5 岁开始写) ； 不过后来并没有神秘嘉宾上场，也没有声泪俱下的宣泄。 无论如何， 这些看似冗长的问答中有不少精辟的言论。 我摘录了一些关于挑选，面试程序员，优秀程序员的特点，和程序设计的句子。下面是这些程序员的心得，和我的几句解释：
|
Coder
|
What they say about good programmer, interview, and design
|
My interpretation
|
|
LISP hacker, early Netscape developer, nightclub owner
|
Stay away from big fan of C++ templates;
Ability to argue their point is important.
Curiosity is a key skill for programmers.
There are people graduating with CS degrees who’d never written C. They started in java and they stayed there. That just seemed bizarre and wrong.
|
不喜欢过度崇拜C++ 模板的程序员；
程序员的表达能力，说服能力好奇心很重要；
很多学生拿到了CS 学位，但是从来没写过C 程序，他们学了Java，仅此而已。 这是非常奇怪和不对的。
|
|
creator of memcached, Perlbal, MogileFS.
|
interview question: Write a class to do arbitrary, bigint manipulation with multiplication and division
|
写一个大数的类，可以做乘除法。
|
|
creator of JSON
|
Good Programmer: They have to read Knuth (TAOCP); they are really literate in whatever language they write to other humans.
I invite the candidate to bring in a piece of code he’s really proud of and walk us thru it.
|
读过Knuth 的TAOCP;
有很强的文字表达能力和沟通能力。
请应聘者带自己最得意的代码来，给大家看看。
|
|
Brendan Eich,
Creator of JavaScript
|
hiring: (rely on referral from team member)
Bright people like each other and can judge each other. I don’t give people puzzles to solve. We give them fairly practical problems, Not esoteric puzzles or math-y things.
|
(他有时通过同事的推荐来招人)
聪明的人会互相欣赏，评价。 我不想通过智力题来判断程序员，我们给应聘者相当实际的问题，而不是那些奇怪的智力题或者数学题。
|
|
Java Architect, author of “Effective Java”
|
About programming:
The older I get, the more I realize it isn’t just about making it work; it’s about producing an artifact that is readable, maintainable, and efficient. … it’s easier to optimized correct code than to correct optimized code.
“do you ever use UML as a design tool?”
No. I think it’s nice to be able to make diagrams that other people can understand. But honestly I can’t even remember which components are supposed to be round or square.
|
关于编程:
我越来越意识到写程序不是仅仅把程序写出来，而是要让你写的程序可读，可维护，并且高效。 优化正确的程序要比改正已优化（但是有错）的程序要容易。
“你曾经用过UML 设计工具么?”
没有。 能把设计画成图，让别人理解当然很好。 但是说实话我记不起来哪些模块应该是圆形，哪些是方形。
|
|
creator of Erlang, and OTP.
|
Interview question:
“what was the most fun project you ever wrote; show me the code for this stuff; how would you solve this problem?”
I’m not so hung up on what they know about language X or Y. they are either good at all languages or good at none.
You have to have a good memory to be a reasonable programmer.
|
面试问题:
“你写过的最好玩的项目是什么? 让我看看代码， 你是怎么解决这个问题的?”
我并不一味要求他们已经知道某一两种语言。 好的程序员精通一种语言后，就会触类旁通，能学好所有语言。
好记性对一个好程序员很重要。 |
|
Coder
|
What they say about good programmer, interview, and design
|
My interpretation
|
|
Haskell architect, MSR-Cambridge researcher
|
Beautiful Code: agrees with Tony Hoare that good code should obviously have no bugs, rather than having no obvious bugs. but “looking at the bare code may not be enough, it’s not a characteristic of beautiful code that you should be able to just look at the bare code and see why it’s right. (AVL tree is one example)
|
漂亮的代码: 像Tony Hoare 说的那样 – 它们明显没有bug; 而不是没有明显的bug.
但是“漂亮”并不意味着看着源代码就能马上读懂。 例如 AVL 树, 光看代码你不懂为什么这些子树要转来转去。但是如果你理解了它的核心思想，看到它维护了这个不变量 (invariant) 从而保证 log 级的访问速度，你就会说，”啊，明显理当如此。”
|
|
In charge of Research at Google, NASA.
Made fun of PowerPoint AutoContent Wizard
|
Advice to school: Teach more on team work. “when I was in school, working as a team was called cheating”.
Successful programmer:
The bravado and willingness to “go ahead” with incomplete but essential info.
Interview: I don’t like the trick puzzle questions. It’s important to have someone that you can get along with. More, Can they technically do what they said they can do? You really want to have people write code on the board.
XP, pair programming: 10% of the time is to share is important, but if doing it most of the time, it won’t be as effective.
UML: I never liked any of these UML-type of tools. If you can’t do it in the language itself that’s a weakness of the language.
|
学校教育:
应该教更多的团队合作，“我上学的时候，团队合作被认为是作弊” (现在有些学校还是这样)。
成功的程序员:
他们有勇气和意愿 “开始干”。 “我只要懂得我需要的，就可以开始干活了”， 而不是“我得完全理解某个领域，才能开始”。
面试: 不喜欢用智力题目，要依赖于面对面的问答来判断这个应聘者是否能够和团队合得来，更重要的是，让他们在黑板上写代码，看看他们是否真的能“说到做到”。
XP, 结对编程: 10% 的时间用来交流是很重要的，但是如果大部分时间都用来结对，那效率不会太高。
UML: 我从来不喜欢这类工具，如果你不能在计算机语言中表达(UML 要表达的东西)， 那这是这种语言的弱点。
|
|
Help created Common Lisp and Scheme, Emacs
|
