我和 Google 的故事

也许有人看见过我批判 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 受气呢?无论你走到哪里,那个地方就随你而改进。

Google:三星-苹果案跟 Android 无关

Apple和三星的侵权世纪大战第一阶段落下帷幕,以陪审团认定三星全面抄袭侵权赔偿10.5亿美元告终。所有被判侵权的都是三星制造的 Android手机,所以大家也在盯着Google看,尤其是在Google豪赌收购摩托罗拉并号称是要拿起专利武器保护广大Android制造商的声明 下。

最近Google发出了完整的回应,简而言之就是说几乎三星所有侵权的专利都跟Android操作系统的核心无关,潜台词就是说“全是三星自己咗(zuo一声)的”:

法院将会同时审查侵权和专利的合法性,这大部分都跟核心的Android操作系统无关,有些则还在经美国专利局的重新核查 中。移动领域是一个快速发展的行业,所有人──包括刚加入进来的新军──都是在十年前的想法基础上创造新的想法。我们跟自己的合作商一起合作为消费者提供 创新和便宜的产品,我们不希望受到任何阻碍。

如果你真的仔细用过三星那些被判侵权的设备,不管是三星自己重改Android的UI、硬件的外形设计、包装的设计甚至是连接usb的dock接口的设计,你就知道三星确实是自己咗的。

关于 Win 8 RT 你应该知道的 15 件事

这次的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%这样说。

为什么没有人收服 Email?

编者按:本文作者Gentry Underwood是一名软件设计师兼Orchestra公司CEO(该公司目前正在开发一款名为Mailbox的移动端email应用)。这篇文章详尽地论述了email的一些历史问题、缺陷和目前的一些改进手段。同时,作者也以行业的眼光,解释了为什么到现在为止,都没有一家公司成功收服email这个存在了半个多世纪的老古董。

每个人都在抱怨email——抱怨我们的收件箱常常被各种邮件淹没,抱怨自己不堪重负,哭诉自己和邮箱都失控了…

不仅如此,最近,关于改造email的声音也是不绝于耳。Jordan Crook说自己恨透了email,MG Siegler也狠了心要戒它,不过Alan Henry又反驳道,“不,你不可以。”而广大普通民众还唠叨着要让Gmail加速,让Yahoo!奋力追上,或者,假使上面的两家公司都有负所托,他们也指望着能够有一个团队,有任何一个团队,可以站出来,推出一款更好的产品。尽管人人都认为现在的email烂透了,但是,关于要如何“修理”email,大家似乎都只是大眼瞪小眼,手足无措。

在Orchestra,我们对email的问题已经深挖了一阵子。改造email是一个众所周知的挑战,不过,我们当中的很多发现还是让我们自个儿吃了一惊。现在,我就来说说,当前的email坏在哪儿,想要修理它,又需要解决什么问题。

Email坏在哪儿

email带给我们的焦虑和痛苦,可以归罪于下面的几点:

1.我们收到了太多太多我们压根不关心的邮件…好在,过滤器帮了一部分忙

现在,我们每收到一封重要的邮件,就必定会受到几封来自其他闲杂人等,我们压根不想收到的邮件。这事想起来就来气:突然就会有盏小灯熄灭,提醒我们收到了一封信新邮件。然后,当我们看到这封邮件时,就会禁不住想:“到底是谁把我的注意力’授权’于你的?”

而之所以有这个问题,这里还要扯进一点email的历史——email是在那个整个互联网都只有几百个科学家和工程师使用的年代被造出来的。那会儿,大家压根就不会收到什么垃圾邮件。这也是为什么,现在某个人的email的地址会向所有人敞开大门,并让它们肆无忌惮地闯进来。

不 过,好消息是,现在这个问题在很大程度上已经可以被解决了。尽管我们现在没法强迫其他人把我们的地址从它们的CC(抄送)列表中移除,但是我们的垃圾邮件 过滤器在过去的几年还是表现不错的。事实上,垃圾邮件占到了所有邮件的78%,不过大部分垃圾邮件都没有机会在我们面前现身。而那部分没有被成功过滤的邮 件,我们可以有几种方式将其揪出并分解掉——在拆分垃圾邮件方面,Gmail的过滤器做得很不错,而诸如SaneBox, Unroll.me这样的服务,以及Gmail的重要邮件收件箱,则可以自动将那些不是很重要的邮件打入冷宫。还有一种法子是,你可以花一个小时收集那些自己压根不会阅读的邮件,并取消订阅——这么做之后,你的整个人生都将改变!

2.很多email都像懒婆娘的裹脚布——又臭又长…好在,好多人现在都学会了“收敛”

即便你已经将那些垃圾邮件清理干净,读我们收件箱中的一些重要邮件还是很费事。有的时候是发件人的问题,有的时候,就是怪发件人选错了工具。

不过,在“言简意赅避免啰嗦”方面,我们还是有在进步的。在那些古老的年月中,我们写的email堪比实体信件。但现在,我们会选择给对方发即时消息,短信,tweet,还有其他形式的,以短见长的信息。越来越多的人开始发现短消息的价值,而这也开始改变我们对什么是“可在社会上被广泛接受的”通信规则这个问题的认知。

不过,这种转变总的还是需要时间,而在强制推行这种做法方面,我们也可以说是无能为力。当各大公司想着用一些更切中要害的工具直接取代email时(此时我想到了Google waveShortmail),他们看到了整个网络效应的阴暗面:假如你的解决方案要求所有人都替换服务,那你想都别想!

不过,小团队倒是可以在一些特定的情景下取代email,用用别的工具。比如说,Asana公司就试图在工作组的通信中取代email。还有,我们Orchestra开发的工具就可以避免情侣拿各种琐事塞满对方的收件箱。诸如这样的工具可以在很大程度上减少email的统治,但是这类服务必须跟email并存,没有办法直接取代email。

3.大部分的email客户端都很菜

不足之处主要可以归为以下几点:

1、沟通是很重要,但是组织同样重要。现 在,市面上那些古老的email客户端都是为了不同用户之间的“沟通”而设计的。没错,沟通是很重要,但是,这只是用户实际情况的一部分。我们的收件箱很 多时候也充当着to-do list(代办事项列表)的角色,这里面同样有我们要干的任务,但现在里面却是一团糟,完全没有组织性。

2、它们…慢得像蜗牛。 我们能收到那么多邮件,但是邮箱中的整个工作进度却相当慢。光是加载并处理一条消息就要老半天,而且,一个时延加另一个时延…时延何其多啊。还有,邮箱里 面经常还有一些隐藏的快捷键功能,但是大部分用户都对此一无所知。这其实可以归结到交互设计的问题,这里面还潜藏着巨大的机会。

3、它们简直就是台式机时代的老古董。我们口袋里面的移动设备已经改变了一切。但是,大部分的移动邮件客户端却只是传统桌面版的压缩版,根本没有把移动设备的天然优势给利用起来。但实际上,我们可以借助移动设备的这些特点更好地控制我们的收件箱,不过这类工具的设计和开发也需要一定时间。

改进改进再改进…答案藏在收件箱

当我们在开发Mailbox这款产品时,我们逐渐意识到改进email的最大机会就在于,重构收件箱。而这种方法的好处是,你不用抛弃email,但你的整个体验却改变了。MG Siegler最近也说道:

“问题的解决不是在于要取代email。这个方法被试过太多太多次,也失败过太多太多次了;而是在于我们怎么看待email(即它该被怎么用)。”

很 多其他公司也得到了相同的结论,也把目光瞄准了改造收件箱,这其中最引人瞩目的就包括Sparrow, Fluent, Ritual, MailPilot, Postbox和.Mail。不过,考虑到email的市场如此广大,目前市场上的竞争者其实还是凤毛麟角。而且,这类公司中有些关门大吉了,有些被收购 了,还有些其实压根没有脱离email早期的一些概念。

既然这里面的机会庞大,为什么只有可怜巴巴这么些公司想要重塑用户的收件箱呢?因为…尽管大家对email这个工具都再熟悉不过,但实际,要在改造email上有所作为,你需要克服很多很多苦难:

技术难关要攻克。假 如你想改造一个用户数庞大的email,那就意味着你要在跟那些古老的邮件协议和无穷无尽的棘手问题打交道的同时,管理一大批的数据。Sparrow团队 花了近十年时间开发Sparrow自家的email引擎。而Gmail团队也才在最近,增加了iOS端Gmail服务中的消息推送这个看似很小的功能。而 说道我们自家的服务Mailbox,我们估计了一下,在高峰期,每服务10万个用户,都意味着我们要在每秒处理成百上千条的消息。这在技术上,需要攻克很 大的难题。

设计客户端是个苦差事。email客户端的设计师们面临着这样一个难题:这款产品的优势要大 到足以刺激用户去使用一款新工具,而与此同时,他们又必须保证整个产品的界面设计对用户来说足够熟悉,足够直观。即便目前的email体系烂透了,大家的 习惯也没那么容易改变。而一款好的设计又要在用户的整体体验上带给他们足够的甜头,这个问题实在不简单。

商业模式也是个问题。尽 管有大批的用户在使用email,但是在这个领域要赚到钱也绝非易事。假如一个创业公司要推出一个成功的业务,那么它提供的产品或服务就必须比用户可以随 手获得的免费版要好很多,而这种产品需要时间的打磨。这类跟email叫板的公司需要很多扶持,但是很多投资人却对这个领域避之不及。举个例 子:Fluent的关门大吉在很大程度上就要归罪于资金不够。

要么干一番大事业,要么一边呆着去

既 然解决email问题如此困难,那为什么我们还要飞蛾扑火呢?因为…这真真正正是个问题,而且是个影响所有人的问题。而现在,改造的时机来了:移动互联时 代为我们将email的用户体验变得既快速,又讨人欢喜,提供了大大的机会——当然,也埋伏着令人恐惧的挑战。我们想好了,带上我们的鲜血,汗水和泪水, 干一番大事业!

via TC