程序员,告诉他们被打断的真实代价

简介:

对程序员来 说,打断是低效率的最大原因之一。说实话,这种情况可能对任何人来说都是这样,只是对程序员而言相更糟糕一些。我举个例子来解释吧,比如有一个做销售的 人,他的大部分时间可能就花在接打电话或者在不同会议之间交替的途中了。在某一个会议上,或者某一次会议之前的回顾过程中,对销售人员来说,一次中断的代 价意味着他花在处理被打断上的时间。比如一次摇头,或者“我刚讲到哪儿了?噢,我想起来了。”

再比如一个经理,他的一天总是充满了一系列没完没了的中断。在管理层面,我发现到了中午却仍然没有做完计划中的第一件事是很常见的。Paul Graham写过一篇非常好的文章,是关于管理者和他所说的“制作者(maker)”的每一天的不同本质。而程序员,很显然的就包括在“制作者”这个分类中。

中断对于一个程序员来说是如此的不同。你坐在电脑前,现在有十二个调用在调用栈中。一个显示器上是精心挑选的输入集,它们将会输入到负责生成内容的 一个复杂表格中。另一个显示器上有着舒服的暗色调主题的IDE,调试器的当前行泛着愤怒的黄光。你为了这一刻已经工作了50分钟了——终于输入了正确的 值;搞明白了事件触发的顺序;成功通过了正好数量的foreach和while循环,每一个都花了个好几分钟时间;在异常触发前设置好断点,使得你跳转到 代码库另一侧的一些处理程序上。就在现在,这个非常时刻,你意识到了为什么Orders集合中有22个物品,你搞明白了 _underbilledCustomerCount 值是什么,你还匆匆忙忙写下”8xZ204330Kd”这个字符串,因为它是一个从一些随机数和全局唯一标示符(GUID)的组合自动生成的验证码,你还 没搞懂GUID,但是你也不想去搞懂它,因为你只需要知道这个字符串是什么就可以了。现在这个时候,你已经完全陶醉了,因为你马上就要揭开在这个第三方库 函数调用中到底是什么引发了一个未将对象引用设置到对象的实例的异常(null reference exception),你非常确定那就是 ——

“嗨!!!事情做得怎么样了?对了,你也觉得客户订单崩溃的事情很糟糕吧?或许你能给我一个解决它的预计完成时间(ETA)?”
screenshot

卧槽!!!!

项目主管刚刚在你即将按下下一条指令时,在你打算使用“跳过”而不是“进入”时吓了你一跳。他唠唠叨叨的讲述自己或者是客户或者是其他什么事情的重 要性,反正你是没在听,因为你一边在极力控制着失去所有调试的前后联系的暴怒,一边在提前思考怎么样再能回到二十分钟前的那个状态。但这些都无济于事,项 目主管的老大看见他正在跟你讨论,也走了过来。现在你的邻桌上爆发了一场的关于Initrode账户的讨论,十分吵闹,并充斥着莫名其妙的 buzzword bingo(译者注:一种游戏)和一些关于“在球门区处理比赛”的体育隐喻等等。当吵闹结束的时候,你在六西格玛(译者注:一种商业管理战略,详见[维基 百科]维基百科)体制中黑带三段的手下乖乖就范。你知道自己得点一个披萨,在晚上7点大家都走了再来做这件事儿,这样才能够安安静静的工作。你现在能做的只有摇摇头,然后想着“ 8xZ204330Kd 到底代表着什么?我为什么要写下这东西?”

但接下来才是真正雪上加霜的时刻。当你尝试着向向项目主管解释刚刚的举动对你的工作成果造成多了多么毁灭性的破坏时,他哼你一声并告诉你不要这么耸 人听闻。他也总是在想,为什么程序员总是跟女主演一样过于戏剧性。同样,不管你多少次说明,你的非技术的同伴也搞不懂你的苦衷。试想你的工作差不多就是整 天走来走去,不停要求别人更新进度以及接受来自上层的同样的要求,理解程序员们风格迥异的工作模式的确不是易事。以上两种角色我都曾扮演过,而现在我每天 用相当大一部分时间做策划和管理活动。我必须抑制住不时的走到我的队伍所在的地方并打断他们来获得一丁点信息的冲动,即使我能用这些信息发一封邮件,或者 将他们加到已解决事件列表中。项目管理,或是其他管理者们,都有十分现实的问题,其中许多涉及到试图给合作伙伴,客户或内部员工提供及时的支持。在他们看 来,事务或者问题都是可以被打断的。

好了,别担心,我想我有一个方法能让你能够向他们证明,跟他们的工作相比,一个中断对于你的工作成果有多么毁灭性的影响。换句话说,能够让别人理解 对于你来说,一个中断不仅仅是一个马上就能补回来的耽搁这么简单,而是毁掉了你直到那个时间点之前的所有工作。以下就是该方法。

邀请你的项目管理,经理,销售或者其他什么人,让他们坐在凳子上,然后告诉他们你的小幽默。打开记事本软件,输入一串3到4位的数字,就像这样:

123
234
345
543
432
321
999
888
777

现在,告诉他们将这些数字用心算加起来。只能盯着屏幕或者在口中默念,不能写下任何东西,也不能输入任何内容。他可能会笑你,但你可能用一顿午饭赌他五分钟之内连仅仅是得到一个答案都无法完成。他可能接着笑话你并且开始尝试。

你只需双手抱头惬意地坐下来,给他半分钟或者更长的时间,慢慢听他念念有词地计算。然后拿起你的手机打给他的办公室。如果他无视这个电话,开口问他是否准备接这个电话,因为这通电话有可能很重要。他可能会嘀咕一会儿,不得不重头开始。

再给他30秒或者更多时间,跟他说:“嗯,比想象的难是吧。你现在加到哪儿了?知道我经常想到哪个数字吗?333。这数儿挺有意思。噢,也有可能是 221。也可能是加起来是9365的一些数。瞧瞧这些数字,你说是吧?哎哟,说了些废话,不好意思,你在集中注意力啊。我闭嘴我闭嘴。”

再等一分钟。拿出你的电话,假装对着没有人听的话筒大声的说话,模拟一通电话。开始背诵想象出来的电话号码,装出一副羞怯和歉意的表情。

一分钟后,突然告诉他今天你的工作状态非常低落,问问他是否还要让你将那三样东西,以及四五件其他东西加到六七个即将到来的业绩展示的幻灯片上。噢,天呐,你又提到数字了,你个坏人。

最后给他一分钟。告诉他只剩下20秒了,或许是30秒,也可能是25秒。不管是多少,他现在正是关键时刻。哈哈好吧,你知道他会失败的。那就提前感 谢他请你吃午餐吧。但是,如果他答应以后当你编程 — 事实上就像是整天在脑子里追踪一连串数字 — 的时候,不再不停的对你做刚刚你对他所做的那些事情,就让他留着那午餐钱吧。

原文链接: DaedTech 翻译: 伯乐在线 - Hacker_YHJ

文章转载自 开源中国社区 [http://www.oschina.net]

相关文章
|
1月前
|
机器学习/深度学习 人工智能 程序员
大模型时代的思考:小心陷入ChatLLMs构建的蜜糖陷阱-基于人类反馈的间接(反向)驯化-你是否有注意到?
本文探讨了大模型基于人类反馈训练的原理及其潜在风险,特别是大模型在迎合用户需求时可能带来的“蜜糖陷阱”。通过实际案例分析,强调了理性使用大模型的重要性,提出了保持批判性思维、明确人机协作边界、提升人类判断力和创新能力等建议,旨在让大模型真正为人类服务,而不是限制人类思维。
|
5月前
|
安全
线程操纵术并行策略问题之ForkJoinTask提交任务的问题如何解决
线程操纵术并行策略问题之ForkJoinTask提交任务的问题如何解决
|
5月前
|
敏捷开发 测试技术 持续交付
编码过程中有效地管理时间和精力,避免陷入无休止的调试循环
编码过程中有效地管理时间和精力,避免陷入无休止的调试循环
|
7月前
|
算法 程序员
为何程序员在编写程序时难以一次性将所有代码完美无瑕地完成,而是需要经历反复修改Bug的过程?
为何程序员在编写程序时难以一次性将所有代码完美无瑕地完成,而是需要经历反复修改Bug的过程?
71 7
|
7月前
|
监控 安全
线程死循环是多线程应用程序开发过程中一个难以忽视的问题,它源于线程在执行过程中因逻辑错误或不可预见的竞争状态而陷入永久运行的状态,严重影响系统的稳定性和资源利用率。那么,如何精准定位并妥善处理线程死循环现象,并在编码阶段就规避潜在风险呢?谈谈你的看法~
避免线程死循环的关键策略包括使用同步机制(如锁和信号量)、减少共享可变状态、设置超时、利用监控工具、定期代码审查和测试、异常处理及设计简洁线程逻辑。通过这些方法,可降低竞态条件、死锁风险,提升程序稳定性和可靠性。
104 0
|
7月前
|
存储 监控 并行计算
线程操纵术之更优雅的并行策略
本文详细介绍了并行编程以及一些并行问题案例中的真实业务场景。
112646 2
|
7月前
在程序运行过程中,线程的状态是什么?进来看看就通透了
在程序运行过程中,线程的状态是什么?进来看看就通透了
57 0
代码优雅之道——如何干掉过多的if else
代码优雅之道——如何干掉过多的if else
129 0
关于《生成器运行时机导致的难以察觉的 bug》勘误
关于《生成器运行时机导致的难以察觉的 bug》勘误
81 0
生成器运行时机导致的难以察觉的 bug
生成器运行时机导致的难以察觉的 bug
76 0

相关实验场景

更多