顶级程序员的心得 - Coders at Work

[原文在 www.yishan.cc 连载,  现在合成一篇]

  

读了 “Coders at Work”,   对15 位顶级程序员的采访， 总共600页。 从采访的模式看，有点像“艺术人生”， 一般都是音乐起，讲小时候的故事，你怎么开始写程序的?  (Brad 同学 5 岁开始写) ； 不过后来并没有神秘嘉宾上场，也没有声泪俱下的宣泄。 无论如何， 这些看似冗长的问答中有不少精辟的言论。 我摘录了一些关于挑选，面试程序员，优秀程序员的特点，和程序设计的句子。下面是这些程序员的心得，和我的几句解释：

 

Coder

 

What they say about good programmer, interview, and design

 

 

 

My interpretation

 

 

 

Jamie Zawinski,

 

 

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，仅此而已。 这是非常奇怪和不对的。

 

 

Brad Fitzpatrick

creator of memcached, Perlbal, MogileFS.

 

interview question:

Write a class to do arbitrary, bigint manipulation with multiplication and division

 

 

写一个大数的类，可以做乘除法。

 

 

Douglas Crockford 

 

 

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.

 

 

(他有时通过同事的推荐来招人) 

 

 

聪明的人会互相欣赏，评价。 我不想通过智力题来判断程序员，我们给应聘者相当实际的问题，而不是那些奇怪的智力题或者数学题。

 

 

Joshua Bloch

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 设计工具么?”

 

 

没有。 能把设计画成图，让别人理解当然很好。 但是说实话我记不起来哪些模块应该是圆形，哪些是方形。

 

 

Joe Armstrong

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

 

 

 

Simon Peyton Jones

 

 

 

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 级的访问速度，你就会说，”啊，明显理当如此。”

 

 

 

Peter Norvig

 

 

 

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 要表达的东西)， 那这是这种语言的弱点。

 

 

 

 

 

 

 

 

Guy Steele

 

 

Help created Common Lisp and Scheme, Emacs

 

 

 

Code writing:

 

 

When you are writing code you’re writing as much for human readers as for the computer.

 

 

 

 

 

 

 

If efficiency is important, I’ll often resort to a trick. And then I realize that will mislead a human.  And you have to comment it or do something to flag that, to make it more readable.

 

 

 

 

代码:

 

 

当你写代码的时候，你写给机器看，同时也写给人看。

 

 

 

 

 

 

 

如果效率很重要，我会用一些小技巧。 这些技巧会误导读代码的人，你得加上注释，或者类似的东西标注一下，让它更可读。

 

 

 

 

 

 

 

 

Peter Norvig 同学在NASA 工作的时候，参与了NASA 的一个著名事故的调查 ( 1999 年“火星气候卫星” 因导航出现重大错误而坠入火星大气层)。  从他在这本书的问答中，我们可以看到一个大略的错误发生过程:

 

 

 

  1)      软件外包公司对于 mission-critical 的软件模块有很完备的检查和测试，但是对于其他模块则没有完备的管理。

 

 

  2)      程序员写了一个不重要的log 功能，其中用英制 (磅* 英尺) 表示力,  但是 NASA 用“牛顿”=  千克*米/(秒*秒)

 

  3)      外包公司接到一个新的工程，他们进行了软件重用，log 功能中记录的力被重用为导航功能的输入参数，成为 mission-critical 的模块。

                      //错误: 一个模块从 non-mission-critical 变成 mission-critical 没有经历必要的复审和测试。

 

 

  4)      这个新的工程由发包公司 Lockheed (洛克希德公司) 交给了客户 JPL (喷气推进实验室)

 

  5)      火箭带着卫星发射了，在10个月的飞行中，JPL  可以每天两次启动小推进器，来调整太空船的航向，在这一过程中，有人发现了导航功能的一些不正常现象, 于是 -  

 

a.       JPL 发邮件给 Lockheed, 说 – 这个模块有些参数看起来好像不正常…

 

  

b.      Lockheed 回邮件...

 

  

c.       JPL 再发邮件…

 

  

d.      最后没有人再发邮件了

 

 

后来,  JPL的同志认为， Lockheed 的同志们估计已经搞定了。   Lockheed 的同志认为， JPL 的同志们没再追问这个问题，可能已经不是问题了。

 

错误: 这个问题从来没有收录到NASA 的错误跟踪系统 (Bug tracking system)，只是在email 中交流，导致最后没有人对这个问题负责。在错误跟踪系统中，总得有一个人“拥有”这一个bug，这样可以避免推诿责任。 (MSF 也很重视这一点)

 

 

 

十个月之后， 1999年9月23 日，卫星抵达火星大气层，错误的导航参数造成卫星坠入大气层烧毁。 单单卫星的造价就高达一亿两千五百万美元。

 

 

Coder	What they say about good programmer, interview, and design	My interpretation
Dan Ingalls Guru of Smalltalk; inventor of BitBlt operation, working on Lively Kernal now.	Tips on a good technical leader: 1) clear vision; 2) trust people;   get everything figure out, but leave it open to team member to do it. 3) avoid micromanagement.  if you’re worried and you’re insecure, and so you’re feeling like you hve to nail everything down. Alan Kay is a good example for such great leader.	技术带头人: 1) 清楚的远景。没有清楚的远景，只有强大技术能力的团队，就像盲人骑瞎马，还使劲用鞭子抽打，让马快跑。 看起来一度非常拉风，但后来免不了人仰马翻。 2）信任团队，把大方向弄清楚之后，把其他事情交给团队成员去搞清楚。 如果带头人详细规定了所有细节，那么团队成员干得还有什么劲呢？ 3）避免“微观管理”。当你担心或者没有安全感的时候，你当然会希望把所有细节都搞清楚，但是这样反而会出乱子。
L Peter Deutsch veteran of Xerox PARC,  author of Ghostscript; now he is into music composition.	skills of good programmer: intuition – no luck, but experience that had simply gotten internalized so far down that i didn’t have conscious access to the process. programmer – people who feel comfortable swimming around in the world of symbols. programmer vs. coder: "Coder" is strongly associated with the smallest and most narrowly focused part of that whole software building endeavour.   "coder" represents such a small corner of the whole processs. a good title should be: software developer. computer science = enginnering + applied mathematics. I would've thought that the internet was inherently uncontrollable, and i no longer think that. China shows that you can do it pretty effectively.	优秀程序员： 直觉。 但是Peter 说的不是运气，而是长期实践之后成为你思维一部分的东西 - 你不知道推理这些东西出来，正如同你不知道如何推理出直觉。 Peter 认为优秀的程序员必须能在抽象思维 (world of symbols) 中得心应手的人。 程序员 vs. 码农: Peter 认为Coder 把程序员的工作定义得太狭隘了。 就像IT 民工，翻沙，砌墙。  砌墙并不是一个坏工作，但这只是“建筑”这一过程中的一个小部分。 "软件开发者" 应该是一个好名称， 虽然并不全面。 所谓 "计算机科学" 不过是工程加上应用数学。 我原以为互联网是根本上无法控制的。。。
Ken Thompson creator of Unix.	Talented programmers: it's just enthusiasm. you ask them what's the most interesting program they worked on,  get them to describe it and its algorthms and what's going on.  if the ycan't withstand my questioning on their program, then they are not good. enthusiasm is not something you ask directly, but in the conversation you'll come with the enthusiasm-ometer.	优秀程序员的特点: 就是“热情”， 我们有时也说 "passion for technology".  但是在面试的时候你不能问 - 你对计算机技术有热情么?  因为所有回答都是 yes。 你要在场景中， 对话中感觉对方的“热情”。  如果一个念了5-7年计算机专业的人，不能 “两眼放光”地给你讲他自己最得意，最激动人心的项目或算法，不能回答你的深入提问，除了老师的作业和实验室老板叫做的项目之外，没有别的想法。 你觉得这种人有多少 “热情”? Ken 还表达了自己对C++ 的意见，几乎所有这本书采访的牛人都不太喜欢C++， 很有意思，不过这是另外一个话题了。

 

Coder	What they say about good programmer, interview, and design	My interpretation
Fran Allen       first woman winner of Turing Award	Software process:       did software-development process save the IBM/360 project?       it's was absolutely necessary,  but it was painful for the software people to [adjust to] design reviews, design specs, all of this stuff.     good programmer: basic threshold: find out what they're excited about. if they can't get enthusiastic about something,  they're not going to get charged up in a group.	软件流程:       因为IBM/360 项目的软件部分遇到了很大的困难，那时候还没有什么成文的 "软件工程"， Fred Brooks 把管硬件的经理们调来，让他们来管软件部门， 因为硬件是一个相对成熟的产业 - 芯片设计，测试，等等。 这些“不懂软件”的同志们参考硬件产业， 建立了软件工程的基本流程。     从一个成熟的产业中学习，是很有效的办法。 现在我们还可以从软件工程的一些术语中看到硬件的影子 - 例如 smoke test 冒烟测试。   好的程序员: 热情 (前面 Ken 同学也谈到了这一点)
Bernie Cosell czar of PDP-1 pioneer of APPANET,  the core of the later internet	advice to programmer: write a lot of programs. there is very few inherently hard programs. if the code looks very hard, that's almost always an indication that it was poorly thought thruough.   if you have complicated code, put it in an encapulated place. programs are meant to be read.  avoid premature optimization find talented programmers: whether they have the kind of inquiring, curious, precise kind of mind.  quickness of learning, interested in lots of different things, and kind of broadly based. [carefully chosen] puzzle can gives you a glimmer as to how they organized something to approach it.	给程序员的建议: 写很多程序。 世界上难的问题/程序很少， 如果一个人的代码看起来很难，这通常意味着程序员没有想清楚。 如果你必须用很复杂的代码，把它包装起来。 程序是用来给人读的。 避免过早优化。 优秀程序员:   应聘者有没有刨根问底，好奇心, 准确的思维?  能快速地学习么? 是否对很多东西都有兴趣? 是否有很广泛的基础? [仔细挑选的] 智力题能让你看到应聘者是如何组织材料，解决问题的。
Donald Knuth (高德纳) TAOCP, TeX and METAFONT, literate programming     Knuth 在学术界的影响	How I learn programming – basically taking one program that i made up myself and sitting at a machine over a period of some weeks, and kept getting it to work a little better and a little better. Q: Should every programmer be able to read TAOCP? A: I sometimes wonder if I can read them. but even an algorithm like a balanced tree ot AVL tree, i don't use it in m own programs unless i know that it's going t obe a really big tree. what do you use? i use an ordinary binary search tree with a little trick for randomizing it that i just put it.	...

 

[由于在csdn 写博客碰到一些不能解决的问题,  我决定把博客搬到 http://www.cnblogs.com/xinz/ ]