??xml version="1.0" encoding="utf-8" standalone="yes"?>
作者以个体差异开_作者指出,在Y件工E文献中提到q非常大的个体差异:28:1 (for error identification) to 25:1 (for coding ability) to 11:1 (for timing efficiency) to 6:1 (for sizing efficiency)。但不幸的是Q这些差异ƈ没有得到我们_的认识,作ؓ实践者,我们不知道如何鉴别出那些是别?8倍生产力的hQ他们对于按时交付高质量的Y仉帔R要;作ؓ研究者,在案例研I中也没有对个hq行_的区分,q将D对结果的误读。)Q然后引出对目q展带来负作用(影响目q度Q的?'(someone who has negative productivity—that is, someone whose inclusion on a project actually makes the project less efficient.)''Q接着以自q亲nl历的三个例子做了阐qͼ
1. Disfunctional labor relations. 目Q与软g无关Q组被抽C人,却发现生产力提高了;q个案例让作者意识到目中存在让Z易觉察的寚w目生产力产生负媄响的人;
2. Moral rebellion. 作者所带领的项目组中存在一个对公司存在性不认同的hQ导致项目进度滞后,使作者受C软g职业中最差的评hQ?br />
3. Overly high standards. 作者所在的目l由于一个对质量要求非常严的QAQLҎ交的产品不满意,l果D产品q迟不能交付?br />
对待q些人,作者给Z自己的解x案:解雇他们?'(If someone on your project is deliberately delaying its progress, there’s probably only one reasonable solution. Fire them! If you don’t, your team will be sorry, your company will be sorry, and, quite likely, you’ll be sorry as well!)''
如此大的旉差别Q去q?0月䆾Cq?月䆾那可?个月之久啊)Q难道是~辑“手误”Q手误也应该做个解释啊,怎么是不回留言呢。之前我也注意到一些发表的论文Q?0月䆾之前发表的)中刊出的“收稿旉”大概也在今年?Q?月䆾Q当时我q想怎么q么多在我之后收E的却在我之前发表呢Q看来这也许是一U故意行为,“潜规?#8221;Q!Q?/p>
N出版CְZ昄自己发表周期短欺骗广大科研工作者吗Q先不说q本w就是学术不端,重要的是它直接给投稿者带来了巨大的风险——剽H。试想一思想cM的文章如果是在去q?0分之后投E如果发表了Q当然前提是其它期刊刊出的收E时间是真实的)Q那会是什么情况?Q不用说别h肯定认ؓ是我剽窃Q所以收E时间应该是l对真实的,我想q也是这个信息在文章中出现的主要价|Q!Q。另外的问题就是给投稿者的工作?l效l计带来不便Q明明是d的工作量怎么体现的是今年的时_万一领导复查Q怎么说清楚呢?/p>
l论Q再也不向此刊投E了?/p>
斯坦大学上个月在Proceedings of the National Academy of Sciences学报上发布了一个研I结果:“媒体行业中多工h员(multitaskerQ的认知控制”Q强调指Z个显而易见的事实Q从效率的角度考虑同时从事多Q务,l对会媄响工作效率。该研究审视了IT领域中一个广Zh知、却常常Zh忽略的现象:不断出现、正在发生的多Q务工作方式。敏捷实施者们q样写:q下可算有理p团队只开发一个品了Q而且只能有一个品负责h——将旉花在多个d之上l对是效率低下的工作方式?/p>
Wired杂志指出Q虽然其他研I点关注多d工作方式的眼前效果(比如Q办公室里的工作人员l常查邮Ӟq种情况下的工作效率Q,该研I提Z一个不同寻常的问题Q?#8220;要是Zd使用多Q务工作方式会怎么P”Stanford的研I者Clifford Nass、Anthony Wagner和Eyal Ophir调查?62名学生的媒体消费习惯?9名用多d方式最多的学生?2名多d方式最的学生此后参加了两个电脑测试,集中_֊完成手上的测试?/p>
他们使用了一些标准的心理试指标Q研I结果显C出Q经常在多个信息之间{换的学生Q他们会在e-mail、网c视频、聊天和电话之间来回切换Q他们取得的q展q低于不怎么采取多Q务方式的学生。更令研Ih员惊讶的是:在Q务切换能力的试上,“重度媒体多Q务h?#8221;表现更差Q?#8220;g他们qo不相qQ务的q扰的能力更差?#8221;
该研I再ơ强调了认知U学家反复提到的事情Q同时处理多个信息流的输入被认ؓ是hc认知能力的问题?/p>
对于造成差异的原因——被定位使用多Q务方式的人是不是先存在心Z的不健全Q还是说多Q务方式造成了这U情况—?#8220;q是一个需要投入上百万金才能回答的问题,可是我们没有一百万金d得答案?#8221;Nessq么说?/blockquote>Wagner接下来打用脑部造媄Ҏ来研I多d方式的神l学解释Q而Ness会研究儿童人群在多d习惯上的发展?/p>
]]>
文章开头指出,“productivity”Q生产力Q此处译为工作效率)通常被定义ؓ生效能(efficiency)、度?metrics)Q以及在生q程中单位输入得到的产出的衡量。但对IT人员来说Q什么是生效能呢?作者给Z一个非正式的定?#8220;一个有效率的h是指那些能够在指定的旉内以高质量的方式完成指定工作的h?#8221;q引Z一个问题:我们如何做可以员工更有效率Q?
作者援引Mr. Elgan?009q??LComputerworld那期中的一文?#8220;Why Goofing Off at Work Boots Productivity"中的话说Q?
那些偷偷在Fackbook和Twitter上花量旉的办公室“懒鬼”(slacker)比那些全部时间都用来做工作的做更多的工作。墨本大学的研Ih员在一Ҏ的研I中证实了这U真实性。他们的研究发现Q一般来_那些Z个h原因在工作时间内使用Internet的h比不用的人效率高9%?br />
作者指出,管Mr. Elgan没有指出q些研究者是如何衡量生率的Q但他给ZZ么那些在Internet上花Ҏ间的人更h效率的一些原因:
作者接着列D了一些管理者们在不鼓励计算机游戏或|络冲浪的情况下所采用的提高员工效率的方式Q?
作者还举了一个例子,说有个复有创造力的同事把键盘上的F1~F12都附加了新功能:
F1 Accurately reflect what’s in the building’s vending machines.
作者最后指出,作ؓ理者,需要关注如何现实的鼓励员工发挥他们最大的效率Q还需要决定如何来优化工作环境。只要求生效而没有适当的管理支持和资源适得其反。作者认为,不时地准备一块蛋p(不管什么原因)可以鼓励团队和沟通?
By the wayQ作者是国能源部国家核安全理局的CIO?/p>
作者首先介l了在Y仉成和软g开发中涉及的术?技术浩如烟P但是开发者却只坚持某U技术,而必M用其它技术来解决问题。这U现象在开发语a领域也是一栗开发者L使用自己喜欢的语aQ而非解决问题最优的语言Q会造成设计Ҏ的不优?
作者指出在日常开发中了解和用多U编E语a可以带来显著的好处,因ؓ没有M一门语a适用于解x有问题。而语a的存在也主要是由于它适于解决某些特定斚w的问题(在解x些问题方面比其它语言好)Q因此,不断有语a出现和消亡。在~程语言设计和开发中涉及许多需要权衡的因素Q因此,qؓ许多不同的方案和变体预留了空间?
作者指出,大部分单一语言开发者們选择用于通用目的的语aQ像Java、C++{)Q而不是特定的~程语言。通用的编E语a可用于解xq范围的问题Q但它们通常都是提供的折中的解决ҎQ不是太好,也不是太坏。当Ӟ一些单一语言开发者尽力去挖掘语言的高U特性,来将语言的能力发挥到极致Q但q些E序员仍然受制于q门语言实际的限度?
作者指a的选择对开发效率是一个重要因素,选择正确的语a所带来的开发效率的提升是巨大和值得q么d的。作者以?a class="editpage" title="Create 'XML'" href="http://localhost:8080/JSPWiki/Edit.jsp?page=XML">XML的处理ؓ例阐qC此观炏V通用语言Q例如Java在处?a class="editpage" title="Create 'XML'" href="http://localhost:8080/JSPWiki/Edit.jsp?page=XML">XML斚w没有专门设计上的支持Q这使得开发h员在使用通用语言处理XML斚w忍受q种不匹配,来进行拙W的开发,造成非优的解x案。在q种情况下,Z提高效率Q他们通常采用一些代码生成技术,?a class="editpage" title="Create 'XML'" href="http://localhost:8080/JSPWiki/Edit.jsp?page=XML">XML构造块影射为静态编E语a的构造块Q通常是类Q来量~解q种LQ即便如此,q种方式仍然是十分脆q。因为把高度灉|?a class="editpage" title="Create 'XML'" href="http://localhost:8080/JSPWiki/Edit.jsp?page=XML">XML构造块转化Z格的静态的数据cd很容易造成彼此版本的不匚w?a class="editpage" title="Create 'XML'" href="http://localhost:8080/JSPWiki/Edit.jsp?page=XML">XML文的Q何改变都需要新的代码生成、重新构建?...q得通过代码生成获得的一点点好处又被不断l护带来的成本所抉|。相比之下,Python、Perl、Erlang{语a都提供了XML处理模块Q甚臌带版本化功能。更好的像ECMAscript for XML (E4X)和ScalaQ提供了对XML字面量的支持支持Q开发h员可以直接在语言语法中写XML。消除了LQ带来了更简化的代码和更清晰的功能?
作者指出,选择适当的语a所带来的效率的提升q体现在对代码的l护上。作者援引Fred Brooks在《h月神话》中引用的的研究发现_所需开发和l护的工作量与指令的数目Q可以理解ؓ代码行)是指数关p,而且q与所采用的语a无关。假设这个指数值是1.5的话Q那么如果代码行是原来的3倍的话,那么需?倍的开发和l护成本Q如果代码行变ؓ原来?倍,需?1倍的开发和l护成本Q如果代码行变ؓ原来?0倍,那么需?2倍的开发和l护成本。选择正确的语aQ不仅可以减代码行Q更快的提供解决Ҏ和对需要的响应Q这个过E可以变为积极的循环Q更的代码带来更好的缺陷和更容易的增强Q维护)Q这又得用h高兴Q提供免费的q告宣传和反馈,q一步促qY件的发展?
作者指出,多语a~程的一个问题就是如何它们协同工作。这可以分ؓ两类。如果是用于分布式应用集成(即不同的应用用不同的语言Q,那么|络本n通过协议提供了一个中立的ҎQ可以通过|络消息{。如果不是分布式应用Q当前的L开发语aQ比如微软的CLTQ公paq行Ӟ所支持的语a来多Q命令式的、动态的、函数式的,或脚本的。类似的QJVM也从一个单语言q_演化Z个可以支持许多语a的^収ͼ包括JRuby、Scala、Groovy、JavaScript、E4X、Jython和其它的。而且Q在JVM上,q些语言都容易学Q因为都是基于字节码Q这些语a可以与Javaq行互调。因此,JVM提供了一个非常好的方式来为应用的不同部分选择最适合的语a?
作者还指出目前ȝ多语a~程的因素主要有两个Q一个管理因素;另一个开发者认为学习新语言隑ֺ很大。对于第一个因素,理者通常认ؓ只采用一U语a易于理Q因为大安用同L语言Q可以容易的替换开发h员,而且某个开发h员写的代码,大家也都能看懂,避免陷入只有数人才能看懂和l护的局面。作者认U管理者对软g开发和l护所涉及的成本没有充分考虑。在一个JVM或CLR基础之上Q选择合适的语言可以减少代码规模和开发维护的工作量,从而降低系l的L本,而且Q较的pȝ需要更的开发者,q又是一个巨大的成本减少。对于第二个因素Q相比通用语言来说Q那个特定的语言Q像Lisp、Python{都很简l,核心概念q不多,初学者可以很快发现它们更h生力,而且Q以往语言的经验可以帮助你学习新语a。如果你掌握的语a多Q你p更容易的学习一门新语言Q也能发现解决问题的最好方式?
最后,作者以“毕竟Q难道我们真的认为我们已l学到我们所需要的最后一门(l极Q语a了码Q?/strong>”l尾?br />
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Ƣ迎您对自己所在的开发组l对于多语言~程、融合的实践和经验发表看法,谢谢Q?/p>
]]>