职业与工作方法mcdreeamiemusings.com
PowerPoint 之死：害死七个人的那张幻灯片
Death by PowerPoint: the slide that killed seven people (2019)
2022 — 2025，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
文章以哥伦比亚号航天飞机事故为线索，讨论一张信息密集、重点模糊的 PowerPoint 幻灯片如何在 NASA 的风险评估与决策沟通中掩盖关键危险信号，使决策者低估泡沫撞击风险。它借这起悲剧反思技术简报中的版式、叙事和沟通方式如何影响生死攸关的判断。
为什么经久不衰：它把幻灯片设计从审美问题提升到工程安全与组织决策层面，提醒人们信息呈现方式本身可能致命，因此多年后仍值得重读。
HN 评论精选
幻灯片应区分“演示”与“文档”两种用途，双重用途往往两头都做不好。
从 Tufte 的文章链过去，我看到一段关于微软经历的有趣评论：让幻灯片同时充当投影视觉材料和独立讲义，会导致视觉呈现和文档都糟糕，但这却是常见做法。PowerPoint 是展示视觉信息、帮你讲故事或论证观点的工具，做书面文档很糟，那该用文字处理器。我认为这击中很多公司：会议上很多糟糕幻灯片其实是打算会后当文档看的，而很少人意识到这会让演示很糟。讽刺的是，PowerPoint 做讲义不差：如果读者在屏幕上读，一份屏幕形状页面的 PDF 可能接近最优。你只需百分百清楚自己是在做文档还是做演示。
codeflo查看英文原文
Linked from Tufte’s article, I found this interesting comment from someone’s experience at Microsoft: [1] > Attempting to have slides serve both as projected visuals and as stand-alone handouts makes for bad visuals and bad documentation. Yet, this is a typical, acceptable approach. PowerPoint (or Keynote) is a tool for displaying visual information, information that helps you tell your story, make your case, or prove your point. PowerPoint is a terrible tool for making written documents, that's what word processors are for. I think that’s on point for many companies. A lot of the terrible slides you see in meetings are actually intended as documentation after the fact, and few people recognize (or care) that this makes for a terrible presentation. Ironically, I think Powerpoint isn’t such a bad tool for creating handouts. If the intended reader reads the document on their screen instead of printing it, a nice PDF with screen-shaped pages might actually be close to optimal. You just have to be 100% clear whether you’re creating a document or a presentation. [1] http://mamamusings.net/archives/2005/11/19/the_culture_of_the_deck.php
认为该版式适合技术简报，责任在 NASA 的决策与追问，而非幻灯片或供应商。
又一起 NASA 把责任推给供应商工程师的事故，就像挑战者号。标题并不令人放心。工程保守主义本质是通过保守估计建立安全裕度。标题说我们需要小心，因为一块隔热瓦很可能被穿透。如果我没记错，重返前新闻已报道已知隔热瓦损伤，但不知道程度。“NASA 觉得工程师不知道会发生什么，但所有数据都指向损伤不足以危及乘员。”如果你认为他们不知道，那就问他们知道什么！幻灯片上明明写着飞行条件超出测试参数、弹丸质量高得多。在 NASA 工作的人怎么会不懂质量、速度、能量的基本原理到足以提问或自己算一下？幻灯片这样排版是因为它在描述推理过程，形成演绎论证说明担忧如何产生。这是给其他工程师的简报，不是会议演讲或销售推介；它应当正式并包含技术要点摘要。用投影做技术简报早于 PowerPoint。在这个语境下我不觉得排版有问题。
giantg2查看英文原文
Another NASA screw-up that they're trying to pin on the vendor engineers, just like Challenger. The title is not reassuring. Conservatism in engineering is essentially about creating safety margins through conservative estimation. The title is saying we need to be careful because a tile was likely penetrated. Hell, if I remember correctly they were reporting that there was known tile damage on the news before reentry, but that they didn't know the extent. "NASA felt the engineers didn’t know what would happen but that all data pointed to there not being enough damage to put the lives of the crew in danger." If you thought they didn't know, then ask them what they do know! It's right on the slide that flight conditions are outside of test parameters and that the mass of the projectile was much higher. How the F do you work at NASA and not understand the basic principles of mass, velocity, and energy well enough for that to stand out enough to ask questions or run your own calculations... The reason the slide is laid out the way it is, is because it's describing the thought process and creates a deductive argument for how they got to their concern. This is a presentation for a briefing for other engineers, not a conference or sales pitch. It's supposed to be formal and contain the synopsis of technical points. Using projectors for technical briefings predates the use of PowerPoint. I see nothing wrong with the layout in that context. Edit: why downvote without a reply? NASA has a history of blaming vendors when they screw up. This looks like another example to me. The presentation format does not have any issues given the setting and target audience.
灾难根源是航天飞机系统性缺陷与“偏差正常化”，不应归咎于单张幻灯片或单次会议。
Diane Vaughn 的《挑战者号发射决策》把灾难责任错误归给展示类似幻灯片的那场会议。航天飞机设计在 1970 年代末定稿时，他们知道每次发射有 2-3% 的机体损失概率。他们仍计划每年发射 50 次，那意味着每年损失一架航天飞机和机组！航天飞机有数百个关键缺陷，那个展示此类幻灯片的“偏差正常化”会议是每次发射的例行部分。对每个不可接受情况，他们都要说服自己通过某种缓解（或不缓解）可以接受。类似事情不可避免，然后就会对那场会议细节互相指责。其他所有载人航天器都有逃逸系统，能把乘员从失败火箭上带走。挑战者号乘员在爆炸中幸存，但加强乘员舱撞海时死亡。哥伦比亚号宇航员死于“任何速度都不安全”的热防护系统。早期航天飞机发射时非常担心隔热瓦破裂脱落，几次侥幸后他们以为没事，但并非如此。
PaulHoule查看英文原文
Diane Vaughn's The Challenger Launch Decision misattributes responsibility for the disaster to the meeting in which a similar slide was shown. When the shuttle design was finalized in the late 1970s they knew it had a 2-3% chance of a hull loss per launch. They were still planning to launch it 50 times a year so that would have meant losing a shuttle and crew every year! The shuttle had hundreds of critical flaws and that 'normalization of deviance' meeting at which slides like this were shown at was a routine part of each shuttle launch. For each of these unacceptable situations they had to convince themselves that, with some mitigation (or not), they could accept it. It was inevitable that something like this was going to happen and then there would be recriminations about the details of that meeting. Every other crewed space vehicle had an escape system to get the crew away from a failed rocket. The Challenger crew survived the explosion but were killed when the reinforced crew section hit the ocean. Similarly the Colombia astronauts were killed by a thermal protection system that was "unsafe at any speed". When the first few shuttles were launched there was a huge amount of concern about tiles breaking and coming off. Once they'd dodged the bullet a few times they assumed it was alright but it wasn't... In the literature "normalization of deviance" has turned from a formal process used in managing dangerous technology to incidents such as: surgeon takes a crap and goes to work without washing his hands, forklift operator smokes pot and operates, etc.
标题忽略了救援可行性与伦理复杂性，把灾难过度归因于一张幻灯片。
标题预设如果 NASA 认识到重返不可能，乘员本可获救。但这远非明确。这篇文章详述了及时准备救援任务有多难。除了救援是否可能，还有一个巨大问题：是否合乎伦理。如果 NASA 知道哥伦比亚号困在轨道上，那等于明知故犯地把第二组乘员送上有同样潜在问题的飞行器，且没时间缓解。我相信救援乘员会不顾风险自愿前往，但重点是“杀死七人的幻灯片”抹掉了这些问题。
oconnor663查看英文原文
The title presumed that the crew could have been rescued if NASA had recognized that reentry was impossible. But that's far from clear. This article goes into fascinating detail about how difficult it would have been to prepare a rescue mission on time: https://arstechnica.com/science/2016/02/the-audacious-rescue-plan-that-might-have-saved-space-shuttle-columbia/ One huge issue, beyond whether a rescue mission would've been possible, is whether it would've be ethical. If NASA knew that Columbia was stranded in orbit, then it would be knowingly sending a second crew up on a vehicle with the exact same potential problem, with no time to mitigate it. I'm sure a rescue crew would've volunteered despite the risks, but anyway the point is that "the slide that killed seven people" is erasing all of these questions.
历次讨论
同类还值得读
用十年时间自学编程（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