这个故事是我最近在LinkedIn上的Multics论坛上发布的消息的编辑版本。
让你的改动很快就"上线"，是一种强大的激励。 这是关于我在Multics中引入的第一个bug的故事，Multics是20世纪60年代末70年代初在麻省理工学院创建的一个重要操作系统。
我是一名年轻的麻省理工学院新生，被Multics项目录取。我自告奋勇地在dprint（"daemon print"）命令中增加了一个功能，将请求排成队列让行式打印机守护进程处理。其中一位经理要求我记录请求中的副本数，而不是将N个请求添加到队列中。这个改动可以解决涉及删除已完成打印请求的竞赛条件。我做了这些改动，并进行了满意的测试。
我的修改很快就安装好了，我很高兴可以改进系统。但我的兴奋是短暂的，因为我很快就接了办公室的电话，发现自己在听一个愤怒的用户抱怨我弄坏了他的程序。我回去一看，我没有注意到，也没有测试过，子程序的入口点进入同一个源文件。果然，我把它弄坏了。我把它修好了，生活继续。但我一直没有忘记那个电话。我仍然不完美，但脑海里回荡着的那个愤怒的声音，让我在此后的岁月里避免了许多类似的、粗心的错误。
我从这个案例中创造出的箴言是"未经测试的代码不能用"。
测试你的代码。找出你自己的bug，不要让别人发现。避免愤怒的声音
旗下公司