职业与工作方法heeris.id.au
为什么不该打断程序员
Why You Shouldn't Interrupt a Programmer
2013 — 2018，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章用一幅漫画解释为什么打断程序员代价高昂：程序员脑中维护着复杂的多层调用栈式思路，一句随口的提问就可能让整条思路瞬间崩塌，一切从头再来。文章借此说明深度专注对编程工作的重要性。
为什么经久不衰：它把'程序员被打断后思路崩塌'这一普遍体验形象化，多年来反复引发共鸣，对理解深度工作与协作环境的平衡至今仍有参考价值。
HN 评论精选
分享实用技巧：把脑中的思路栈写下来，被打断后可快速恢复。
我曾在处理很有挑战性的遗留代码时，习惯把自己的思路写成类似调用栈的笔记，被打断后能快速恢复状态。这个'思维栈'有时多达12层，全靠在脑中撑住来寻找解法。现在代码质量好了、环境也安静了，但遇到复杂陌生代码时我仍会用这个方法。
calineczka查看英文原文
Once upon a time I was working with a very challenging legacy code and I was building similar constructions in my mind. The office was sometimes noisy and chance of interruption was not that small. So I established a habit of writing kind of stack trace of my own thoughts so that I could easily come back to my state of mind after such thing. It looked like: There is a bug in module X Module is X is calling module Y when user is not yet activated We are creating user subscription We are using current subscription in subscription creation Current subscription is A when user is not activated Current subscription is B when user is activated Probably bug in method c() Think what is going to happen in situation M when changed the implementation to d(). The list sometimes had 12 elements that I was trying to fit in my head to find the solution to the problem. I now work remotely from home (quiet and all that) and most of the code that I work on is of much better quality (another company, better practices) but I still sometimes resort to this method when working on a complicated piece of code that is unfamiliar to me.
从管理者视角类比：打断程序员等于让昂贵设备停机，成本极高。
我把程序员比作制造软件的昂贵设备。公司投资了昂贵设备，就要让它持续产出。把程序员拉去开会，等于让设备闲置停机；打断就像关停整条流水线，重启后还需要时间才能恢复顺畅运转。管理者可以选择让这台昂贵设备满负荷运转，还是频繁启停闲置。
jimbokun查看英文原文
I liken programmers to extremely expensive equipment for manufacturing software. When a company invests in expensive equipment like that, it is very important to keep it producing output. So by sending programmers to meetings, your expensive equipment is sitting idle, offline, producing nothing. Interruptions are like shutting down an entire assembly line. When you turn it in again, it will take time to be running smoothly again. So to the managers and executives, it is your choice how to utilize this highly specialized, very expensive equipment. You can try to keep it running at full capacity, or frequently start it up and shut it down, take it offline, and leave it sitting idle.
反驳漫画：与其要求绝对安静，不如养成把思路写下来的习惯。
不能指望同事把你当成需要长时间不受打扰冥想的僧侣。应对打断是每个程序员都该掌握的技能，越资深、协作越多就越重要。高产的程序员往往靠把东西写下来解决问题——漫画里的人如果有纸笔，随手画出脑中的流程图就行。非要靠脑子撑住如此复杂的结构，只是自设失败。
twblalock查看英文原文
It's not reasonable to expect your coworkers to treat you like a monk who needs to spend long hours in uninterrupted deep thought and reflection. Avoiding the cognitive penalty of interruptions is a skill that every programmer should develop. It's a big win in terms of productivity, and it only becomes more important when you become more senior and need to collaborate more frequently with other teams or provide support to other developers. Collaboration is where true productivity comes from anyway, rather than raw coding skill (above a certain baseline of competence, of course.) In my experience, productive programmers often avoid the problem by just writing stuff down. If the guy in the comic strip had a pen and paper he could have quickly drawn those flowcharts he had in his head. Or he could have typed his ideas in comments or in a text file. But if he tries to hold such a complicated structure in his head, to the extent that he can't have a conversation with another person, he's just needlessly setting himself up for failure. I doubt he would make it through a lunch break or even a bathroom break if he can so easily lose track of what he is doing.
管理者视角：深度专注需求人人皆有，但让团队互不打扰反而更难。
我管理程序员、架构师、分析师、项目经理和业务流程人员，我认为这适用于所有人——凡是凭脑子被雇用的高学历者都是如此。不过让人互不打扰很难，讽刺的是，当每个人都觉得自己做的事需要'特殊专注'时，反而更难做到，这张图可能还会加重这种心态。
eksemplar查看英文原文
I manage programmers, architects, analytics, project managers and business process operators. I think this applies to all of them. Basically anyone with a higher education that was hired for their brain, works like this. Sorting a business process or a benefit model of hundreds of postits to figure out the most efficient way for a team to perform a task isn’t really that different from fixing a piece of software. Having people not disturb each other is hard though. I’ve managed different teams, and the funny thing is, that it’s even harder to get people not to disturb each other when they all think that what they do requires special concentration. So this funny little illustration of the issue actually makes it harder because it might make my programmers think they require more concentration than their coworkers. :p
历次讨论
同类还值得读
用十年时间自学编程（1998）
Teach Yourself Programming in Ten Years (1998)
Peter Norvig 1998 年的经典文章，回应“21天/24小时学会编程”一类速成书，主张真正精通编程需要约十年持续、有意识的练习。
职业与工作方法上首页 11 次 · 2007–2025norvig.com编辑精选如何成为一名程序员：简短、全面而个人的总结
How to be a Programmer: A Short, Comprehensive, and Personal Summary
一篇广为流传的程序员成长指南，作者以个人经验系统总结了成为优秀程序员所需的各项技能——从调试、测试、沟通到团队协作与身心健康。
职业与工作方法上首页 6 次 · 2008–2015samizdat.mines.edu编辑精选不要自称程序员
Don't Call Yourself a Programmer
经典职业建议文章劝软件工程师不要把自己局限在“程序员”这个标签上，而要从公司业务角度说明自己创造的价值；文中讨论了成本中心与利润中心、头衔、求职与职业选择，也顺带批评了学术界的价…
职业与工作方法上首页 5 次 · 2011–2021kalzumeus.com编辑精选创作者的日程与经理的日程
Maker's Schedule, Manager's Schedule (2009)
Paul Graham 在这篇文章里把时间表分成两类：管理者的日程以小时为单位，会议可以填满一天；创作者（程序员、写作者等）的日程则以半天为单位，需要长时间不被打断的连续块。
职业与工作方法上首页 5 次 · 2009–2021paulgraham.com编辑精选为什么程序员的薪酬不与生产力成正比
Why programmers are not paid in proportion to their productivity
讨论为什么程序员的薪酬往往不随其生产力成比例增长：生产力难以客观量化，薪酬更多受组织预算、岗位定价和个人议价能力影响。
职业与工作方法上首页 5 次 · 2009–2022johndcook.com