原文：A Generation Lost in the Bazaar （发表于 ACM Queue vol. 10, no. 8, 2012）
作者：保尔－亨宁·凯普（Poul-Henning Kamp） 翻译：@李松峰

13年前，新兴的草根开源软件运动如火如荼，而Eric Raymond的《大教堂与集市》（O’Reilly Media, 2001）一书则重新定义了我们的词汇表，几乎预言了瀑布模型和大型软件公司的终结。这本书有煽动性，但却没有说服我。与此同时，由于我正全身心投入开源 运动，也就情不自禁地宁愿相信他是对的。

而今年夏天我带到海滨别墅来的这本书，同样有煽动性，比Raymond那本更甚（但这本书在提到《大教堂与集市》时是相当正面的），那就是 Frederick P. Brooks的《设计原本》（Addison-Wesley Professional, 2010）。Brooks这本书不断引发我的共鸣，我也越来越佩服他的语言表达能力和他提出的观点，然而越是有共鸣，就越感到难过和失望。

13年前，正值.COM热潮涌动，年轻的Web程序员比比皆是，辍学创业的大学生也屡见不鲜。在向其中一些人传授过去那些编程技巧的同时，我也获得 了很多乐趣。像什么测试恢复备份、写脚本安装操作系统、版本控制等等。当然，现在再看，也就那么回事（有些事并不像你印象中那么激动人心，对吧）。而且， 我们已经无路可逃，整个.COM时代总体上对IT/CS而言就是一场灾难，尤其对软件质量和Unix来说，更是如此。

好像从来没有人分析过.COM泛滥那些年，IT行业增长了多少。以我个人的经验，我估计整个行业（包括IT行业由此新增的就业机会）大概增长了两个数量级，或者更确切地说，达到了原来的百分之一万（100倍）。

学会计算机编程很容易，就像学会用钉子把两块木板钉到一起一样简单。但问题是——打个不恰当的比方，市场对“钉在一起的两块木板”的需求，除了“自 豪的爷爷”的那点天伦之乐以外，真的是太小了。而且，由此再进一步学习钉椅子或做碗橱，都需要天分、实践和训练。我们增长的这99倍恰恰都来自那些既没有 实践经验，又没有受过良好训练的人。等这些人有时间学习和接受训练了，聚会已然结束，大多数人失去了工作。可以乐观地假定那些坚持下来的人最有天分，而且 经验也最多，即便如此我们还是无路可逃，因为作为IT专业人士，由于缺乏基本功，他们大多数都很滥！

不幸的是，Raymond鼓吹的——与.COM泡沫之前精心建造大教堂的理念恰恰相反的集市模因（meme）1——“对付过去就行”（just hack it），并没有随.COM泡沫破裂灰飞烟灭。今天，Unix这艘大船正因为难堪重负而迅速沉没。

1 模因论是基于达尔文进化论的观点解释文化进化规律的新理论。参见这里。——译者注

我刚升级了自己的笔记本电脑。到现在，我运行FreeBSD开发版已经足足有18个年头了，但从源代码编译我的Spartan工作环境仍然要花一整天时间，因为它必须理清头绪，在Raymond那乱糟糟的软件集市中建起一座大教堂来。

宏观上讲，FreeBSD的Ports Collection会尽力为这个集市画一幅地图，以便FreeBSD用户轻易找到自己的应用。目前来看，这幅地图由22 198个文件构成，而这些文件就是集市中每个摊位的简要说明：用寥寥数语告诉你某个摊位卖什么，要了解详细信息再去哪里找。此外，还有23 214个Makefile，告诉你可以对每个摊位上的软件做什么。这些Makefile还想告诉你都有哪些选择，要选择什么，以及不作选择时用什么默认值 比较明智。为方便起见，这幅地图还提供24 400个补丁文件，以便弥补这些玩艺儿在制作工艺上的瑕疵，但一般来说，还是因为它们携带（portability ）不便，所以才催生了这些补丁。

最后，地图提供一些建设性意见，比如要是你想要www/firefox，那得先得到devel/nspr、security/nss、databases/sqlite3，等等。在你手拿地图，查到这些依赖，以及这些依赖的依赖之后，你会发现自己的购物清单上已经记满了122个包，你必须在能买www/firefox之前买全它们。

当然啦，模块化和代码重用都是好主意。可是，就算在最简单的情况下，CS/IT的代码重用信条在集市里也没有用武之地：FreeBSD Ports Collection中的软件最少都包含1342个复制粘贴加密算法。

如果有人奋不顾身或者偏听偏信，非要代码重用，结果真制造出了自身完备且无依赖的软件包，那要换得这个容易管理的包，享受代码重用的成果，就算多花点银子也值啊！但这样的事并没有发生过：各种包把Web搞得一团糟， 随便依赖，互相纠缠，代码越重用，浪费越严重。

举个浪费的例子吧。Sam Leffler的graphics/libtiff是前面提到在安装www/firefox之前必须安装的122个包中的一个，但安装后的Firefox浏览器却无法渲染TIFF图片。问题出在哪里我还没来得及查清楚，但这122个包中的10个需要Perl，7个需要Python；这其中又有一个devel/glib20，同时依赖着Perl和Python，至于为什么，我到现在都没想通。

继续往下看你的购物清单，你会不断发现满足彼得定律的应用。所谓彼得定律，就是说在一个根据人的业绩、成就和价值来提拔人的组织中，最终会把一些人提拔到他们并不胜任的位置上。这个定律经常被通俗地说成“把员工提拔到他们不胜任的职位”。软件行业也一样，你会发现自己需要三个不同版本的make程序、一个宏处理器、一个汇编器和其他一些必要的包。而在这个“食物链”末端，则是libtool，它试图掩盖一个事实，即在Unix中没有构建共享库的标准方式。的确没有适用于所有Unix变体的标准方式——比如给ld(1)命令加个标签之类的；而此时彼得定律就适用了：这个工作被交给了libtool。此时此刻，彼得定律确实牛，devel/libtool的源代码达到了414 740行，而其中有一半是测试用例。原则上讲，这倒是值得称赞的，但实际上这却是彼得定律的结果：这些测试煞费苦心地在那里验证一个本来就不该存在的问题的复杂方案是否功能齐备！更让人抓狂的是，其中31 085行代码都保存在一个叫configure的shell脚本里，代码格式之乱，任谁也难看明白。这样做是想让configure脚本执行大约200个自动测试，从而免除用户手工配置libtool之苦。这个想法很滥，早在1980年代刚刚出现时，就招来很多非议。因为源代码是靠configure脚本的伪装才让人感觉它可移植的，而实际上并非真正可移植。可以说它是配置思想的余孽。

1980年代出现过很多不同的Unix实现：Cray-1s及其24位指针、Amdahl UTS主机Unix、来自微机制造商的大量的SysV+BSD混搭、Data General等公司开发的准Unix“垫片”，甚至连油漆厂Mark Williams都有纯粹的Unix克隆Coherent。

当时的configure脚本是手写的，用于检测当前系统是BSD还是SysV风格的Unix，然后根据检测结果把一个或另一个Makefile（有时候还带一个.h文件）复制到指定位置。后来，这个configure脚本的神通越来越大，而且不折不扣地印证了彼得定律。我们没有看到Unix采用标准做法来消除对该脚本的依赖，反倒是有人写了一个叫autoconf的程序，用来自动生成configure脚本。

今天，Unix/Posix一脉的操作系统，就连IBM的z/OS主机版，都跟1980年代那些完全一样；libtool这个configure脚本中的31 085行代码仍然还要检测<sys/stat.h>和<stdlib.h>是否存在，即便是没有这两个文件的Unix变体，在既没有足够内存执行libtool，也没有足够硬盘保存其16MB源代码的情况下。

为什么会这样呢？

由于尚不知晓的原因，autoconf是用晦涩的M4宏语言写的，因而实际的测试代码如下：

## Whether `make' supports order-only prerequisites.AC_CACHE_CHECK([whether ${MAKE-make} supports order-only prerequisites],  [lt_cv_make_order_only],  [mkdir conftest.dir   cd conftest.dir   touch b   touch acat >confmk << 'END'a: b | ca b c:       touch $[]@END  touch c  if ${MAKE-make} -s -q -f confmk >/dev/null 2>&1; then    lt_cv_make_order_only=yes  else    lt_cv_make_order_only=no  fi  cd ..  rm -rf conftest.dir])if test $lt_cv_make_order_only = yes; then  ORDER='|'else  ORDER=''fiAC_SUBST([ORDER])

毋庸讳言，这超出了大多数程序员的承受能力。即便有人有这个能力，但给autoconf指定输入文件都是用复制粘贴的，所以那些涵盖前述“标准测试”的标准宏代码日益膨胀也就很难被发现，而这些宏都是为了处理20年前并不存在的兼容性问题。

我一直不明白：为什么针对我系统里根本没有的Fortan编译器，但libtool的配置探针仍然有不少于26个名字，而且还要再执行26个测试，检测这些根本不存在的Fortran编译器分别支不支持-g选项。也许这就是原因所在。

这是由Raymond在其书中称颂的集市模式导致的悲哀的现实：一坨脓包似的权宜代码，被一群盲目的根本不知IT架构为何物的所谓IT“专业人士” 永无休止地复制着，粘贴着。这事儿放在今天你也许很难相信，但就是在这令人无比尴尬的混沌之下，沉睡着美轮美奂的Unix大教堂的遗迹，而Unix恰恰是 以设计简约、功能实用、执行优雅而著称于世的。（世间荣耀就此消失……）

Brooks提出了很多有见地的观点，其中一个就是所谓质量，只有在某人对它负责时才有意义，而这个“某人”只能是一个人，不能是几个人——二重奏除外。我有点奇怪，为什么Brooks不把Unix作为他这个观点的论据，因为我们可以精确地指出Unix开始走向碎片化的时间点：1990年代初，AT&T抛弃Unix，将其商业化，抢走其架构师的那一刻。

最近几年，不止一个人像Brooks一样得出相同的结论。有些人企图粉饰太平，假装正经，还有人通过制定技术标准的形式来达到类似立法的目的，希冀 着在集市中引入秩序和结构。到目前为止，他们的努力全部以失败告终，因为在集市中迷失的这一代.COM神奇小子，从来就没有见过大教堂，也不可能知道你为 什么需要大教堂，更不用说去想象教堂是个什么样子了。这么挖苦别人，其实我心里也很难过。真的，那些最需要看看《设计原本》的人，可能会发现这本书完全无 法理解。但对于那些怀疑过构建一个Web浏览器居然要使用M4宏来配置autoconf，要写shell脚本，要检测26种Fortran编译器，而且又觉得这怎么说都有点南辕北辙的人，Brooks也谨慎地指出了方向：还有更好的方式。

作者简介：Poul-Henning Kamp (phk@FreeBSD.org) ，26年的计算机程序员，个人网站http://bikeshed.org。他编写的软件以底层构建块的形式被开源和商业产品广泛采用。他最近正在做的项目叫Varnish HTTP加速器，用来加快Facebook这样大访问量网站的响应速度。

（译文完）

也许有人看见过我批判 Google 的那篇英文文章。它好像有一部分片面性，所以被我从英文博客上拿下来了。我一直在反思自己在 Google 的经历，因为在这个公司工作总是感觉不对劲，但是却总也说不清楚为什么。也许现在用自己的母语，我可以得出一个准确一点的结论吧。

受命于危难

先说说我的项目是怎么开始的吧。当我加入的时候，我的老板 Steve Yegge 的小组试图制造一个跨语言的“服务式”编程工具，叫做 Grok。你可以把它想象成 Eclipse 和 Visual Studio, 但是 Grok 的设计目标不只是检索和分析本机的某一种语言的代码，而是大规模的检索和分析 Google 的所有项目，所有语言，所有代码。这包括 Google 的“四大语言”：C++, Java, JavaScript, Python，一些工具性的语言：Sawzall，protobuf 等，还有一些“build file”和所有第三方的库。Grok 的初期设计目标是一个静态的代码索引服务，只要程序员点击任何一个变量或者函数名，就能“准确”的跳转到它定义的位置。动态的编辑功能稍后也在陆续加入。

这种检索不是像 ctags, etags 那种简单的正则表达式匹配，而是像 Eclipse 和 Visual Studio 那样的准确的“语义检索”，所以它必须真正的理解程序语言的语义。在 Grok 诞生以前，市面上和 Google 内部都没有一个工具能正确的支持所有“四大语言”，所以我不得不说，Steve 的项目比起 Google 的其他程序语言相关的项目是相当先进的。

虽然 Grok 的技术含量挺高，但是 Google 的管理层对东西的评价并不是看技术含量的，而是看你有多少“影响力”(impact)，说白了也就是有多少用户。Google 当时本来就只有不到一万个程序员，一个“内部编程工具”能有多少“用户”呢？所以 Grok 比起像 CodeSearch 一类利用正则表达式来查询程序的“低端”项目来说，在管理层心目中并不占任何优势。而且由于其它项目界面好看些，用户多些，Grok 随时有被取消的危险，这使得 Steve 心理压力很大。我就是在这个“危难关头”进入他们的小组的。我当然没蠢到会自己进入这样一个组，但是 Steve 在电话面试时把一切都说得很美好的样子。当时小组里只有三个人：Steve 和另外两个组员。

恐惧和疑惑

当我开始的时候，Grok 小组已经初步完成了 Java 和 JavaScript 的检索模块。但是他们的检索并不是自己设计的，而是从 Eclipse (JDT) 和 JSCompiler (开源后叫 closure compiler) 里面分别“挖取”了对 Java 和 JavaScript 语义检索的部分，修改之后插入到项目里的。Eclipse 的设计非常的不模块化，以至于项目进行了一年多，大家还在忙着解决它带来的各种 bug。

最开头的时候 Steve 给了我两个选择：检索 C++ 或者是 Python。我觉得 C++ 的设计太繁琐，所以就选择了看起来好一点的 Python。Steve 就让我去找一个开源的 Python IDE，然后把里面的语义检索部分挖出来插入到项目里面。可是在看过十个左右的“Python IDE”之后，我发现它们没有一个能够正确的“跳转到定义”。分析其原因，是因为这些 IDE 基本上做的是正则表达式匹配，而完全不理解 Python 的语义。所以我对 Steve 说，我要自己从头写一个。但他反对这个提议，因为他觉得这是三个月的时间之内不可能完成的。不但是我不能，而且就算一个小组的人也不可能完成。就算完成了，他也不想“维护”这些代码。所以他宁愿让我去拿一个不怎么样的开源项目，因为这样“维护”的工作就转嫁到开源项目身上去了。

可是我很清楚的看到，这样一个语义检索，不过是一个抽象解释器 (abstract interpreter)。写解释器是我很在行的，所以我告诉他这是我可以完成的，而且由于设计上的简洁，我的代码的维护代价会比使用一个开源项目小很多。他没有说话。我同时也在进行一些内部培训，看一些视频，折腾 MapReduce 一类的内部工具教程，就这样过了一个星期。我隐约的感觉到 Steve 的不快，因为他不怎么说话了，可是也没有太在意，仍然傻乎乎的到处凑热闹。到了周五的时候，Steve 下午很早就回家了。另一个组员还待在哪里，闷声闷气的。我对她说：“Steve 是不是不高兴了？我知道我说话有点太自信，可能打击到他了。”她好像打满的气球被开了一个孔：“他怎么会被你打击到？你知道他以前做的项目有多厉害吗？他是怕你做不出来。之前有一些 intern 设的目标太高，以至于到最后没有完成他们的项目。你知道我们以前一个类似的项目 JSCompiler，花了多少时间才完成吗？一个小组的人，四年的时间！”于是她打开 Eclipse，把一块代码给我看：“看这一个文件就有 9000 多行代码。你三个月能写出这么多代码吗？”我翻了一下白眼，搞笑似地说：“啊～ 怎么可能有 9000 多行？这些人真的知道怎么写这种代码吗……”

后来具体的对话我忘记了，但是她说得那么战战兢兢的，确实给了我一些压力。再加上 Steve 那个闷声子，真是不好受。所以那个周末我没有出去玩，我下载了一个 Jython，把它的 parser 文件 (ANTLR) 拿出来。自己设计了一个更简单的 AST 数据结构，把这个 parser 生成的 AST 转换成我的结构。然后就开始在上面写一个抽象解释器。由于 Java 的限制，我想出了一个更简洁的用 Java 实现解释器的方法，从而避免了使用繁琐的 visitor pattern。一个周末之后，我做出了一个基本的原型。当然因为 Python 语言的复杂性，有很多细节的东西到后来才完全的实现。

等到星期一的时候，我告诉 Steve 我做了一个原型出来，而且因为我拿了 Jython 的 parser，我们以后可以用这个理由把这代码 merge 回 Jython，给他们提供功能，让他们帮我们维护代码，对两方都有好处。他居然一点也不高兴，把我叫到一个白板前面，板着脸说：“你知道我为什么担心吗？我怕在你离开四个月以后，我还在跟别人说，我仍然在改正我的 intern 代码里的 bug！来，给我讲一下你打算怎么做。”我就画了一个 AST 的类关系图，在每个类插入一个叫 interp 的方法，然后指出这个东西就是一个解释器。最后他豁然开朗了一样，说：“好。我相信你知道你在干什么了。就这样做吧。”

陌路

在 Google 的整个夏天，我都觉得跟其他人没有共同语言。我感兴趣的东西，他们一点都不了解，所以我也不想谈。我觉得不以为然的一些东西，却被捧上了天。总体感觉就是过度“和谐”，像是回到了小学。每个人都像是“祖国的花朵”，对 Google 的一切都赞不绝口。你本来有时不想笑，不想说好话，身边的“社会压力”却让你不得不满脸堆笑，所以很累。没有人说真话，以至于你不知道到底什么好，什么不好。

人们总是喜欢谈论一些人的显赫“地位”，传说他们如何的“牛”。比如，有一次几个人在谈论一个 Google 的“牛人”，说他做了一个多么了不起的项目，很快就升为了 Staff Software Engineer （“Staff”是比“Senior”高一级的职位，Steve 就是个 Staff）。我去看了一下这项目，发现不过就是 JUnit 的“C++ 版本”。JUnit 这东西技术含量本来就是相当低的，做这样一个东西就能当“Staff”，那我岂不是轻而易举就可以成为“Principal”了？哈哈。我心里这样想，但是没有说出来。一个 Staff 就如此，谈到 Google 的两个创始人的时候，有些人就简直是黑白不分了。对他们的各种武断的甚至不讲理的做法，居然都津津乐道。创始人在他们眼里俨然就跟皇帝一样，他们做什么都是对的。甚至有人以自己的办公室在创始人办公室的正下方为豪。这种浮夸和互相吹捧之风，恐怕是在其它公司也少见的。Google 要求员工们保持一种“Googley”的态度，原来就是这样的态度，过度的“正面”和“积极”。美国所崇尚的“个人主义”和“批判性思维”，在 Google 貌似高度缺乏。

另一些时候，我会遇到一些对某种语言或者技术有宗教情绪的人。有一次吃午饭，一个工程师主动坐到我面前，像是在面试我一样，正儿八经的开始自我介绍，后来我们就谈到 C++。我说 C++ 设计实在是太繁琐了，其实很多简单的语言效率并不比 C++ 低，C++ 最近其实在向其它高级语言学一些东西…… 后来这人就不说话了。那天以后我就发现跟他打招呼他都不理了。后来我才发现，在 Google 是不可以指出某种语言，特别是 C++ 的缺点的。C++ 在 Google 的“势力”之大，连 Java 都只能算二流货色。

最搞笑的其实是 Google 总喜欢故弄玄虚，把一些微不足道的东西说得很玄乎。很多文档，视频，活动都挂着“Google Confidential”的标签。等你去看了，却发现其实是众所皆知的东西，没有什么机密可言。可是大部分的实习生们却有一种受宠若惊的感觉，以至于产生优越感。每个星期五，都会有一个“TGIF”，两个创始人会像主持人一样组织一个大会。本来无可非议，但是总感觉气氛过于群情激昂了，有点像小学的时候升国旗开大会的感觉。好不容易大家聚在一起，总是在听新闻发布，不然就是谈工作进度，不然就是表彰某些人。总之，你总是感觉在受到某种挑拨，有一种传销公司大会的感觉。大家轻轻松松一起玩的真正的 party，却非常稀少。

由于 Google “免费”提供一日三餐和娱乐，健身设施，你总是感觉欠了公司什么一样，而其实这些钱都是出自你自己的劳动。而且因为这些设施离工作的地方太近，你总是感觉 Google 在你的生活里无所不在，连玩的时候都在想着它。Steve 经常叫几个人出去 Starbucks 买咖啡，我开头还觉得奇怪，因为 Google 有上好的咖啡机。后来才明白原来他们只是想出去换个环境和人气。一些别的公司的人（比如我寄宿房子的主人）也在疑惑，Google 的员工到底有没有下班的时间。

我就是这样度过在 Google 的每一天，以至于后来我都不怎么在饭桌上吃饭了。自己把饭端到靠墙的吧台去吃，或者坐在“冰激凌吧”跟里面的厨师聊天，省得遇到一些高谈阔论的人无语。我发现自己跟打扫卫生的大妈小妹们也谈得来，她们也喜欢跟我说话。后来我发现有这种感觉的不只是我，另外两个比较厉害的博士生也懒的在那边吃饭了。其中一个说他一个星期就把自己的项目做完了，然后假装仍然在做，免得又被增加任务。这就是所谓“能者多劳”吧。掌握了核心技术的人，往往会有一般程序员几十，上百倍的效率，可是得到的“回报”却是更多的任务量和压力。

皇帝的织布工

虽然 Steve “允许”我自己从头做一个 Python 分析器，但这却不是没有压力的。这种感觉就像是“皇帝的新装”里的织布工一样。我扬言自己会做出精美绝伦的布料，皇帝的大臣们却看不见，所以他们就相当的小心。总是对我很敬畏的样子，有时会来问候一下，做得怎么样了。可是一旦扯到深入的话题，却又怕被看穿其实他们不懂很多东西。因为我的教授们研究 Scheme，所以 Steve 有时候也会很激动的表扬 Scheme，或者类似 Scheme 的语言比如 Clojure。这种奉承真的让我受不了，生搬来的术语都是错乱的，所以经常来回两句之后，他就无语了。为什么程序语言总是引起这种宗教的态度，不是抵制就是膜拜？
有一次一个 Staff Software Engineer 来访。看我在做这个 Python 分析器，很鄙夷的样子，说：“你做那个东西干什么。Python 本来是没有类型的，怎么推导得出类型来？我倒希望 Java 的类型推导做得更好一些，不用手写很多类型。”显然他不知道什么是类型推导，他也不知道如何把 Java 的类型推导做得更好。很多人把自己的命运寄托在语言的设计者身上，自己没有能力去改进它们，所以他们才会对程序语言顶礼膜拜。

压力

直到有一天，我才发现 Steve 为什么这么紧张。那天有另一个“分舵”的 director 来访，给我们做了一个关于“创新”（innovation）的演讲。基本内容就是说，技术上的创新，如果吸引不到用户，那就不算什么创新，拉得到用户的东西才叫创新。完全就是扯淡嘛，可是他那个气势真像是在宣布圣旨一样。

那天下午，这个 director 来到我们的办公室。表情严肃的“审问”Steve：“你说你每天有 5000 个用户。可是 Google 总共还不到 10000 个程序员。你是怎么算的？你把接受你的服务的那些下游项目的用户全都算进去了吧！”唉，想不到大名鼎鼎的 Steve Yegge 在这种钦差大臣面前也只能唯唯诺诺。

我可以说，这个 Python 的东西，虽然没有费特别多力气，但却是 Google 里很少有人可以做出来的。所以实际上这个东西在很大程度上拯救了这个濒临灭亡的项目，因为一旦 Grok 支持所有的“Google 语言”，就会有很多人注意到这个东西，从而会有“影响力”。这确实是后来发生的事，我走了之后，Grok 开始通过 API 给很多项目提供服务，包括 CodeSearch。

Google 给我的那点工资，其实是根本买不起这样的软件的。你可以参考一下像 CodeSonar 之类“静态分析”软件的价格，一份基本上就是我三个月的工资。由于我上学想找点外快，让他们捡了一个便宜。可是这种“上级领导”的压力居然也间接的传到了我身上，而且是以一种非常不尊重的方式。这种感觉就是，你做得再多再出色，你相对于 Google 的“大拿”们，什么都不算。这也许就是 Google 为什么雇佣 Dennis Ritchie, Brian Kernighan, Ken Thompson, Rob Pike, Peter Norvig, Guido van Rossum 等大牛吧。因为它就可以说：“看我们 Google 有这些顶尖牛人，你算个什么，要不断努力！”Steve 不止一次的对我说：“你要为 Google 做出杰出的贡献啊！Google 的东西总是最好的，你要做出 Google 一贯的品质来。你知道 Python 的创造者 Guido 也是 Google 的员工吗？我一定会在他面前给你美言几句。” 这种语气，我好像在几十年前的中国听说过呢？“你要为祖国做出杰出的贡献！”他也许以为我会受宠若惊，可是我心里却不是个滋味。

有时候他又会突然把脸一翻，做出一副“博学”的样子，说：“你得把这个问题解决了。不然的话你的 intern 项目就是一个失败的项目！” 其它组员如果看我貌似心情比较轻松，也会不时的提一下：“这个做完了吗？如果这个做完了，你可以做那个。反正我们有的是事情给你做……” 我心里其实在想，说得轻松，你自己来做一下，看看一年之内你做得出来不。总之他们就是用这种奉承，利诱，竞争，加威胁的方式，想方设法让我多做事情。

本来这系统能做出来就不错了，一个组员却一直催着我写 test。她根本不明白，一个程序并不是写了测试就会是个好程序。这个程序经过我多次的大规模修改甚至推翻重来，即使一早写了测试，那些测试也会很快作废。这种大公司给人灌输的“test-driven”编程方式，在这种创造性的程序设计里是根本就是行不通的。要写出这样一个系统，必须全神贯注，深入到语言的本质。而去写测试，往往会打乱原来的思路，所以测试应该是最后完成之后才写的。当我最后完成这个系统，可以大规模的处理 Python 代码的时候，却听见从她的桌上传来一声沉闷的咆哮：“WRITE–THE–TESTS—”这真的非常 Googley！

结果

最后我顺利完成了整个项目，从头到尾都是我一个人设计实现的（除了 Jython 里的 parser）。现在它每天都会把 Google 所有的 Python 代码索引一遍。很多内部工具比如 CodeSearch 里面的 Python 文件上的链接，都是这东西做出来的。我所有的代码加起来才 4000 行。我怎么也想不通为什么他们一个文件就有 9000 行。

总结

这些就是我对 Google 的印象。有好几次我都看到很不错的工程师进入 Google 之后就销声匿迹了，为 Google “默默奉献”，不再有自己的发明创造。我感觉 Google 就是一个埋没人才的机器，而它的“创造性”的名声，却让越来越多的人才被埋没。主动找上门的人才被埋没了不说，还吞并其它公司，并且对他们施行同样的“Google 文化”，埋没更多的人才。

Google 总是号称自己的工程师“build things ground up”，实际上却总是拿一些现成的代码来修修补补，往往耗费更多的时间。当你真的想要“从头”做起，却发现重重的阻碍和压力。

Google 跟其它公司有一个明显的区别就是，Google 不稀罕你，你不被尊重，你活在某些你说不出他哪里牛的“大牛”的阴影下。我没有很多其他公司的工作经历，但是我面试过其它一些公司。也许它们在技术上或者名气上会比 Google 差一些，可是我能感觉到他们对人才的渴望和尊重。所以如果你有很强的能力，何必去 Google 受气呢？无论你走到哪里，那个地方就随你而改进。

这次的Win 8直接来了一个Win 8 RT， Win 8 Pro兄弟版。很多用户只知道Win 8 RT为 ARM 硬体而设，比 Win 8 Pro价格便宜，比 Win 8 Pro 薄一些，但并不明白两者的本质区别。而下面我们将用15个问题来让你了解什么是Win 8 RT。  

1. Win 8 RT 代表什么？ 

Win NT代表“Win New Technology”，但是微软从来没有官方解释过Win 8 RT代表什么。 

2. 什么时候可以得到Win 8 RT？ 

Win 8 RT 硬件在Win 8发布的时候就可以面市了，应该是在10月26号。 

3. 为什么有两个版本 

微软的硬件商必须要关注赚钱的问题，苹果iPad的成功让我们看到了一个产品要具有销售的可行性。Win RT 搭载ARM处理器的给了制造商制作更好、更便宜、更省电处理器平板的机会。不过因为没有采用标准的Intel X86-style 处理器，平时Windows 的编码都是基于X86的，所以RT版本无法兼容以前的Windows 软件。 

4. Win 8 RT 和 Win 8 Pro 有什么区别？ 

实际上是一个软件问题，但是得从硬件说起，Win 8 Pro是一个PC操作系统；Win 8 RT搭载 ARM 芯片，是智能手机中常用的芯片。所以在 X86 芯片上无法运行Win 8 RT，相反地，英伟达、高通、德州仪器已经签署了制造Win RT芯片的协议。 

5. Win 8 RT是一个PC操作系统吗？ 

可以说是，也可以说不是，因为其系统无法在PC处理器上运行而已；但是微软说过其RT合作厂商会制造RT系统的平板、传统翻盖笔记本、旋转式设备。 

6. Win 8 RT 和 Win 8 Pro的工作方式一样吗？ 

在Surface上比较相似。 RT应用是基于Pro 之前插入的“Metro”（现在的Modern UI）界面的各种小部件。但是不同的是，RT没有Windows Media Player，或者说RT就是Metro+IE+特别定制的RT版微软Office套件。Win 8 Pro 就会有很多复杂的应用和软件了。 

7. 可以单独购买Win 8 RT或者升级到Win 8 RT版本吗？ 

不行！Win 8 RT只会跟微软专用硬件绑定，比如平板。稍后，微软会发布补丁和更新的。 

8. 谁将生产Win 8 RT硬件？ 

现在还有一点说不准，华硕、戴尔、联想、三星都说它们计划生产RT平板。HP现在态度不明朗，东芝因为零部件短缺而退出生产，东芝的芯片供应商是德州仪器，如果东芝退出是因为芯片问题，那没话说，但如果是软件驱动和东芝硬件的兼容问题，就很有意思了。 

9. Win 8 RT 平板看起来怎么样？ 

微软称它可以支持一个播放流体60赫兹的高清动画；也可以通过“碰撞”来交换分享图片、URL、 地图导航以及其他信息。Surface RT 平板可以连续播放8到13小时的高清视屏。 

10. Win 8 RT多少钱？ 

微软说过它会跟已有的ARM处理器平板拥有“竞争性”的价格，有些人猜想是$399，跟苹果iPad差不多；也有人认为是$199，跟亚马逊的Kindle Fire、Google Nexus 7 差不多。 

11. Win 8 RT 和 Win 8 Pro兼容吗？ 

是也不是，因为Win 8 Pro是Win 8 RT的超集。Win 8 RT应用可以在Win 8 Pro上运行，但只有特别订制的Win 8 Pro应用能在 Win 8 RT上运行。 

12. 我可以在Win 8 RT 上运行我的老软件吗？ 

不行！专为Win 8、Win 7、 Win Vista, Win XP设计的软件不能在Win 8 RT上运行，这是一个全新的版本。 

13. 如何运行Win 8 RT上的软件？ 

微软将发布一款为RT特制的Word, Excel, PowerPoint 以及 OneNote，最适合触摸以及低功耗，所以它很有可能会缺少几个PC上Office 软件的特点。但是IE10 和资源管理器会包含进来，其他的应用，用户可以从 Windows Store购买，所以到时候应用是RT 平板很重要的一部分。 

14. 开发者怎么看Win 8 RT？ 

目前许多开发者只把Win 8 RT当做一个实验气球，一个市场代理商表示，直到这周一他们才开始把Win 8 应用上架，如果被证明市场可行，其他的公司也会效仿；而微软那边则允诺90%提交到Windows 8 Store 的应用会在RT上运行。 

15. Windows Phone 8 

微软说过Windows 8 和 Windows Phone 8 的核是通用的，所以开发者可以轻松把Windows Phone 8 转移到 Windows 8上来，但是需要做出一定的修改。 

至于 Windows Phone 8 apps能不能轻松移植到Win 8 RT 上，还不是很清晰。但是目前已有的例子：Rick Walrond, 文字游戏AlphaDrops开发者表示他可以采用原来Windows Phone 90%的源代码。

优秀的程序员都有什么共同之处？工作经验？薪水待遇？完成任务花的时间的多少？事实证明，跟这些都不相关。

很奇怪，来自同一个公司的程序员们的表现都基本上处在同一水平。为什么？

这最重要的因素是他们所处的工作环境能给他们提供的舒适程度：“… 最能干的程序员所工作的公司几乎都能给他们最大的隐私权，最大的个人空间，最大的控制他们的物理空间的自由度，最少的外界干扰。”

来自： 《Quiet: The Power of Introverts in a World That Can’t Stop Talking》：

为了证明这些，DeMarco和他的同事Timothy Lister设计了一个称之为“Coding War”竞赛的研究计划。这个竞赛的目的是要能清楚最好的程序员和最烂的程序员都有哪些特征；大约有来自92个公司的600名程序员参加了竞赛。他们每个 人都要设计，开发，测试一个程序，在上班时间，在他们平时工作的地方完成。每个参与者都有一位来自同一个公司的同伴。然而，他们之间相互独立，没有任何的 联系。后来证明这是这个竞赛的一个至关重要的特点。

当结果出来后，这些人的编程能力被证明有着巨大的差距。最优秀的和最差的之间的效能比是10：1。顶级程序员比中等水平的程序员也要高出2.5倍。 当 DeMarco 和 Lister 试图解开是什么导致这样惊人的差距时，那些他们以为可能的因素——比如工作阅历，薪资待遇，甚至完成竞赛题花去的时间长短——这些都跟这样的结果关系不 大。具有10年工作经验的程序员并不比只有2年经验的表现的优秀。有一半处于中上等水平的程序员的收入比余下一半处于中下等水平的程序员的收入要少10% ——尽管前者比后者的能力有的要高出两倍。那些编写出“零错误”程序的程序员相较于那些程序中有错误的程序员，他们完成竞赛题所花的时间更少，而不是更 多。

这是一个迷，但是他们发现了一个很有意思的线索：来自相同公司的程序员或多或少都处在同一能力水平，即使是他们并不在一起工作。这是因为那些顶级程 序员所工作的公司几乎都能给他们最大的隐私权，最大的个人空间，最大的控制他们的物理空间的自由度和最少的外界干扰。最有效率的程序员中有62%的人说他 们的公司尊重他们的隐私，而相对的那些表现最差的程序员中只有19%这样说。最差的程序员中有76%的人说经常被没必要的因素干扰，而那些最优秀的程序员 中只有38%这样说。