Tag Archives: Go

Bill Campbell

  继续“八卦牛人”系列。此前两篇写的是Michael BurryMax Levchin。这次是刚刚去世的Bill Campbell。

  Bill Campbell是学教育心理学的,最早做过大学橄榄球队的教练。后来进入Apple主管销售。然后加入GO创业团队。关于这段传奇,我去年专门写过Startup: A Silicon Valley Adventure的读后感。经过这段艰难创业,Bill Campbell建立了个人品牌。开始扮演后来广为人知的“硅谷CEO教练”的角色。

  我猜更多人是通过A16Z的The Hard Thing About Hard Things认识Bill Campbell的。他给处在艰难时刻的Ben Horowitz的支持和指导,让人嫉妒。尤其是Horowitz接受他的建议,在公司大规模裁员、分拆的风口浪尖,退掉去纽约的机票,留在办公室勇敢面对团队,“帮别人把东西搬上车”。这是Horowitz在各种场合反复提到的“关键时刻”。

  

  渡过了“关键时刻”,一个合格的管理者就诞生了。搜索网络,可以看到更多Bill Campbell帮助企业家解决问题的故事。

  Flipboard的Mike McCue提过,他面临自己最大客户AT&T的威胁,用Bill Campbell的思维工具做出了关键决策:否决卖软件做私有项目的思路,坚持公有云服务的路数。关键的是,经过这次讨论,此前有强烈分歧的管理层达成了一致。

  Zynga的Mark Pincus在公司陷入困境的时候也受Bill Campbell的辅导。他获得的建议主要包括:减少操控细节,改进自己和团队的沟通方式,不再在谈话中压制员工,高管定期讨论公司战略,CEO定期对全团队All Hands……Mark Pincus此时承受巨大压力。很多人劝Bill Campbell不必去帮他,太晚了,可能没用。但Bill Campbell还是去了。

  Google的Larry Page处理狂妄自大的Android之父Andy Rubin,明显是Bill Campbell在幕后推动的。

  Facebook的Mark Zuckerberg顶着所有管理层和投资人的压力,拒绝把公司卖给Yahoo。这导致了整个管理层全部辞职。Peter Thiel也很不满意。Zuckerberg一直说那是他最艰难的时刻,据说这个阶段他和Bill Campbell定期交流。

  Steve Jobs和Campbell的交流比较隐秘。外界只知道著名的两周一次的散步,不了解内容。Jobs说Campbell会逼他把不成形的思路理清楚。后来由于Campbell也和Google走得很近,Jobs很不满意,就终止了合作。尽管如此,Bill Campbell去世时Apple官方还是表达了哀悼并推迟了新产品的发布。

  不过他的行为也不是没有引起争议过。在2010年Twitter公司激烈的人事动荡中,Bill Campbell扮演了一个凶狠而不忠的角色。当时Ev Williams因为缓慢低效的决策不得人心,即将要丢掉CEO的位置。Dick Costolo是Twitter的COO,很有希望接任CEO。而Bill Campbell并不是Twitter董事会的正式成员,作为所谓的“CEO教练“列席董事会会议。然而Bill Campbell推动董事会解雇了Ev Williams,尽管后者一直很信赖他。戏剧性的是,之后他又试图突然解雇Dick Costolo。Nick Bilton在他的书Hatching Twitter里把这件事捅了出来,引起轩然大波。直到去世之前,Bill Campbell都被记者们反复追问这件事。

  有一次我在朋友圈说:“又是Bill Campbell,真希望和他聊聊”。经纬的投资人熊飞留言:“KPCB在Soundcloud上的podcast有两期对Bill Campbell采访,推荐”。大家感兴趣可以去听一下这个

招聘程序员、《北京沉没》和Go语言性能

  先转发一篇招聘,我的朋友在做云计算方面的创业,招Flex/Erlang/Python程序员。工作地点在北京,有兴趣的人可以点进去看一看

  5、6月BLOG更新频率明显变慢了,有人问我是不是开始玩微博了,还有人问是不是在准备跳槽。都不是,最近公私事都有些忙,懈怠了,不好意思。另外随着年龄变老,似乎越来越倾向更长篇幅的写作,零碎的想法大多懒得动手敲(记得科学松鼠会上翻译过一篇报道,研究人员发现年龄和写作博客的长度成正比,没搜索到链接)。还是该放松点儿,有长则长,可短就短。只要写出来,总会有价值。

  前两天北京下大雨内涝。豆瓣上马上出现了一篇与此有关的小说《北京沉没》,得到众多推荐,大家都在殷切等待小说的后续情节。

  关于编程语言的性能向来是个大水坑,有诸多争论。前不久,Google公司的Robert Hundt刚刚发表了一篇论文 Loop Recognition in C++/Java/Go/Scala.,,发布了一个简明而紧凑的Performance Benchmarks,分别对C++, Go, Java, Scala四种语言进行性能比较。测试包使用的loop finding算法实现中不涉及任何高级语言特性,只使用了各语言的基础设施:基本容器类、循环和选择、内存分配机制等。文中的主要结论是在32位系统下C++程序最快,常规条件下Java语言运行时间是C++程序的12.6倍,Go语言为7倍;相同的语言条件,不同实现效果差距很大,例如:C++语言如果采用一般教科书知识的“学生式”实现,会比有经验工程师精心优化后的结果慢8倍以上。而Java语言的主要瓶颈在于其内存回收机制,如果采用SPEC优化,则速度起码提高3倍,如果在64位系统下,性能比32位系统提高超过1倍。更多细节,大家可以直接看论文。

  论文对Google自己人发明的Go语言并没有太推崇,认为其性能还比不上C++,开发难度又高于Java。于是Go语言的团队来劲了,刚在官方BLOG上指出,Go语言版本的算法还有很大的优化余地。他们使用了Go开发包里提供的性能测试工具对代码进行了改善,运行速度提高了10倍以上,而申请的内存降低了6倍。

  这篇论文在其他语言社群内也掀起不少讨论。编程语言的性能比较往往涉及到很多因素(编程者的经验和风格,比较题目与不同语言的特性之间的契合等)。对于实际工程而言,选择编程语言的着眼点应该是现有资源和经验,并考虑混合编程。我个人在pFind项目的经验是,保守些,尽量利用团队内多数人熟悉的技术。如果项目负责人只顾着添经验追时髦,把手头的正事当作尝试新技术的小白鼠,十有八九要坏事。