《高效能程序员的修炼》一一路向前冲

一路向前冲

高效能程序员的修炼
就运营Stack Overflow这个公司而言,我采用的商业策略全来自一个人,而且只有这一个人:Curtis Armstrong。

更准确地说,是Curtis Armstrong在1985年的经典荒诞青春喜剧《再见人生》(《Better Off Dead》)中所扮演的Charles De Mar。当他被问到如何从一个特别险峻的高山上滑雪下去的时候,他回答道:

沿着那条路下去,一定要快。如果有什么东西挡住了你的去路……绕开它!

在我们宣布Stack Overflow公司成立之后的5个月时间里,我们完成了下面这些事情:

  •  组建了一支国际化的团队;
  •  在Area 511上制定了新建问答网站所需遵循的一个全新的民主开放流程;
  •  发布了大约24个社区驱动的Stack Exchange网络子站点;
  •  为每个站点实现了独立的“元”2(meta)讨论以及实时聊天功能;
  •  发布了新版本的Careers(职业生涯)和Jobs(工作)子站点;
  •  开发并开源了Stack Exchange数据浏览工具(http://data.stackexchange.com),方便用户查看和分享我们收集到的所有数据;

 敲定了Stack Exchange应用程序编程接口的第一个版本。通过使用这些接口,你可以基于我们的问答平台来构建你自己的应用。
坦率地说,我还是有些担心我们走得不够快……

现在市面上已经出现了一些Stack Overflow引擎的复制品。我想说他们干得不错!我为能创造出一些值得复制的东西而感到骄傲。如果我们仅能做到帮助整个世界远离那些老旧的、破损严重而叽嘎乱响的、类似于phpBB3和vBulletin4那样的公告牌系统—从那里获取信息就像在一条奔流不息的臭水沟里淘金一样—那已经是我的奢望了。

作为一个公司,我们的既定目标是要与网络世界和谐共生,我们的使命是让互联网变得更好(哪怕我们只能带来一些细微的改进)。我发誓,这是真的!我们把它白纸黑字写下来了,并且时时处处都在践行。我们没曾想过要推翻谁或者占有什么东西。我们只是热爱社区,并且乐于为我们的问题找到完美的答案。所以在这个过程中,如果有任何东西挡住了我们的路,请放心,我们不会大打出手。我们会绕开。然后继续向前,快速进步。因此,如果那些抄袭者想要跟上我们的话,他们也得行动快点。

我想,也许只有我们公司才会把Charles De Mar当成业务顾问,但“贵在神速”策略绝不是我们首创的。例如,Google的某些项目看起来就深得“博伊德5迭代法则”的精髓。

博伊德认为,空战中取胜的主要决定因素不是观察、定向、计划以及更好地执行,而是观察、定向、计划以及更快地执行。换句话说,能不能取胜就看人们能够多快地执行迭代。博伊德暗示,迭代的速度胜过迭代的质量。

说起迭代的速度,大家肯定会想到Google Chrome。

Chrome的第一版和第二版已经是一个相当不错的浏览器了。整个项目一直在以一种很快的速度向前推进。结果呢?恕我直言,目前它已经是这个星球上最好的浏览器了。Google一开始并没有浏览器产品,而是平地起高楼,前后才用了不到两年的时间。值得注意的是,微软的IE浏览器从第七版升级到第八版所用的时间,却比Chrome的整个开发过程还要长。而到IE 9发布的时候—尽管它看起来像是微软产品史上最好的一款浏览器,也是最给力的一次技术升级—但它一推出就会被Firefox和Chrome完全比下去。6

Google的Android7项目是另一个极好的例子。Android不一定非得比iPhone好(事实上它也肯定比不上iPhone;它一直表现平平,直到最近的几个版本才有所起色)。但这不要紧,他们只需以更快的速度去改进。Google以令人难以置信的、极快的速度推出了Froyo,Gingerbread,Honeycomb等多个版本。没错,苹果有更好的品位(这个无可争议),而且它把用户体验也做到了极致。不过,如果按照苹果现在的进展速度,它在几年以后的移动产品领域里就只能做Google的陪衬了。这是必然的!

所以,除非我另作声明,否则我们就会遵循跟Android和Chrome团队一样的策略。我们会沿着那条路,非常快地向前冲。如果有东西挡住了去路,我们就会绕开它!

Tim O’Reilly@timoreilly在Twitter上发的一条短讯:

“Larry Page8对‘决策的速度和正确性之间的相互关系’是这么评论的:只有又快又好的决定,而在反应迟缓的情况下不可能做出好的决定来。”

时间: 2024-09-20 21:01:21

《高效能程序员的修炼》一一路向前冲的相关文章

《高效能程序员的修炼》一导读

译者序 高效能程序员的修炼出版社的冀康一开始来找我谈翻译这本书的时候,我的第一反应是:这兄弟真是不知道我现在有多忙!我每天要处理200多封邮件:在资源有限的情况下经常要同时带6-7个项目,而且每个项目的交付计划都很紧,压力很大:每天起码工作12个小时,有时候还要熬夜跟美国同事开会:周六基本上也是工作状态--我哪里还有空来翻译书?! 后来,当我了解到这本书的作者是Stack Overflow网站的创始人Jeff Atwood,还有书的内容实际上就是从作者的博客网站Coding Horror精选而来

读书笔记--《高效能程序员的修炼》

        初次邂逅......        最近小编抽空看了一本书,书的名字叫做<高效能程序员的修炼>,从这本书的名字就能看出来,软件开发远不只是写代码那么简单,你要学会的是高效能的工作,这让小编想到了去年读过的一本书<高效能人士的七个习惯>,有兴趣的小伙伴可以看看哦,受益匪浅,<高效能程序员的修炼>这本书从人文角度而非技术角度去阐释了作为一个程序员,应该具备的基本素质,所以小编在看这本书的过程中,感到非常的有共鸣,通俗易懂,又很贴近小逼啊工作和生活中的实际,

《高效能程序员的修炼》一向橡皮鸭求助

向橡皮鸭求助 高效能程序员的修炼 在Stack Exchange上,我们坚持要求提出问题的人需要在自己的问题上多下些功夫,而且我们在这方面有些偏执.那就是说,当你开始要提问题的时候,你应该: 用足够多的细节来描述发生的状况,这样我们可以顺着你的描述继续研究下去.即使在你所在的特定领域里我们并不是专家,你也要向我们提供必要的背景情况,这样我们可以了解到底发生了什么事情. 告诉我们你为什么需要知道答案.你怎么会出现在这里?是闲来无事的好奇,还是在某个项目里遇到了障碍?我们不是要求你长篇大论地讲生活故

《高效能程序员的修炼》一如何培养写作习惯

如何培养写作习惯 高效能程序员的修炼 我得忏悔一下:程序员同胞们,从某种程度上来说,我创办的Stack Overflow网站"耍"了大家. 在你找来棍棒准备揍我之前,请允许我先解释一下. 在过去的6年时间里,我越来越坚定地有了这样一个想法,那就是:成为一名杰出的程序员其实跟写代码没有太大的关系.做程序员确实需要一些技能,当然,还要有坚韧不拔的精神.但除此之外,更重要的还是要有良好的沟通技巧. 杰出的程序员跟勉强过得去的程序员之间的差别,不在于他们掌握了多少种编程语言,也不在于他们谁更擅

《高效能程序员的修炼》一大道至简

大道至简 高效能程序员的修炼 作者在Twitter上发的一条短讯: "你永远都有简化的空间." 11:29 AM – 2012-5-21 Rich Skrenta在"Code is our enemy"(代码是我们的敌人)一文中是这么说的: 代码不是什么好东西.代码会随着时间的推移慢慢腐烂.代码需要周期性的维护.代码里还藏有bug.新增功能意味着旧的代码需要被修改.你的代码越多,bug能藏身的地方就越多,迁出(checkout)或者编译的时间也就越长,新员工理解你的

《高效能程序员的修炼》一磨刀不误砍柴工

磨刀不误砍柴工 高效能程序员的修炼作为一名软件开发人员,你该如何磨快你的锯子? "磨锯子"实际上是一个代名词,泛指一切编程以外的活动(不必编写代码),而这些活动(从理论上来说)能使你成为一名更出色的程序员.这个词源自于Covey的一本书:<高效能人士的7个习惯>(<The 7 Habits of Highly Effective People>).1 有个人在山间漫步,偶遇一位伐木工.他便停下来观察这位伐木工,看他热火朝天地锯一棵很大的树.他发现这位伐木工干得大

《高效能程序员的修炼》一性能致胜

性能致胜 高效能程序员的修炼在Stack Overflow和Stack Exchange上,我们总是非常强调性能.不仅仅因为我们是性能的发烧友(我很内疚),也因为我们认为速度是一个竞争优势.已经有大量的实验数据表明,网站载入和显示的速度越慢,使用它的人就会越少. Google发现,显示10个结果的网页需要0.4秒来生成,显示30个结果的网页需要0.9秒来生成.半秒钟的延迟会造成20%的流量下降.半秒钟的延迟就扼杀了用户的满意度. 在A/B1测试中,亚马逊试着以100毫秒为单位逐步增加页面的延迟,

《高效能程序员的修炼》一学会读源代码

学会读源代码 高效能程序员的修炼在"沟通"这个复杂的领域里,写出能让人类领会并理解的连贯段落比敲出几行不至于让解释器或编译器"呕吐"的软件代码要难得多. 这就是为什么--就软件开发而言--所有的文档大概都是很差劲的.而且,由于为人写作比为机器写作要困难得多,恐怕在可预见的将来,文档还会继续差劲下去.对此,你基本上是无能为力的. 除了做一件事-- "卢克1,学着去读源代码." JavaScript"始终带有源代码"是一股革命性的

《高效能程序员的修炼》一关于多任务的神话

关于多任务的神话 高效能程序员的修炼在<质量·软件·管理:系统思维(第1卷)>一书中,Gerald Weinberg1提出了一个经验法则,用以计算由于切换项目而引起的浪费. 根据Weinberg的计算,哪怕在你的工作负荷中只是增加一个项目,也会严重地影响你的效率.你会损失20%的时间.当你增加第三个项目的时候,你会有将近一半的时间浪费在任务切换上面. 即便你同一时间只做一个项目,这种问题也可能会发生.轻易被电子邮件.电话以及即时消息打断你正在进行的工作,其影响可能是深远的,就像BBC2的这个研