程序員最恐怖的夢魘是什么？
這是Quora上的一個問題，其中Mick的回答獲得了13.5k“贊同”，他如此回憶道：
曾經有位心理學的博士雇我查一個BUG，程序是他的一個學生寫的，經常會出現奇怪的輸出。程序的功能是，從文件中讀取數據，提出50個問題，進行一系列計算，然后基于這位博士的研究來得出一個分數。程序跑在大學的一臺3B2上。他給我演示了程序，確認這個Bug可以重現——每次在問題之間切換的時候，總會閃出一些奇怪的字符。我覺得這應該很簡單，所以答應了他，并且我們同意按小時付費。
Day1
我來到這臺3B2面前，用那個學生的帳號登錄，找到了用C寫的源代碼，并開始測試。代碼可讀性非常差，所有的代碼都寫在了一行，變量名都是三個字母，而且還是隨機組合的！真慶幸我當初選擇按小時收費。我把代碼格式化為習慣的風格，這樣看起來多少還能讀。
做完之后，我用curses庫移到屏幕上一個點，打印一個問題和答案，然后等待回應。但是在打印出***行之后，出現了一些亂碼，過了大約1/2秒之后，亂碼被問題覆蓋掉。這個問題應該很容易解決，只有五個地方需要打印信息，所有的地方都出現了一閃而過的亂碼。小意思，只要刪掉mvpwintw()應該就ok了。我刪掉之后開始編譯，覺得問題差不多解決了。但是運行的時候，干擾信息又出現了！只是亂碼變了，但是癥狀還是一樣！
我檢查了一下代碼，發現竟然回到了我改之前的樣子！15個文件，混亂的格式，三個字母的變量。當初為什么不備份一下代碼呢，真想射自己一槍。我再一次格式化它們，這次把代碼放到三個文件中，以不同的名字命名。然后備份了整個文件夾，并且將權限設置為只讀。編譯之后，一切正常。一運行，這個文件夾中又出現了15個文件！我改過之后的源代碼沒有被刪除，然后干擾信息又回來了。
我明白了，這一定是在硬盤的某個地方的代碼，在編譯的時候會將程序添加到我修改的代碼中去。所以我準備搜索一下include區域（/usr/include），因為我們用的是研究的版本，所以除了kernel別的代碼都在機器上。頭文件太多了，所以在3B2上搜索需要花一些時間。以上，就是***天的工作了。
Day2
從磁盤的搜索中沒有得到什么結果，這說明這些亂碼要么是被加密了，要么就是在lib中的某個地方。但是我沒有搜到，我決定搜索所有的文本文件，這次花的時間比昨天更長，第二天就這這樣過去了。
Day3
沒有結果。字符串是加密的。我只好根據所有的頭文件來一點一點查了。這會花費相當多的時間，我們同時還警告了學校，可能有人得到了Phelps博士計算機的root權限。但他們卻對此并不關心，可能只是一臺實驗室的計算機吧。
我打開#include文件，卻沒有發現代碼。后來發現這些都被編譯成一個文件了。也沒什么關系，畢竟我們有源代碼，大不了就重新編譯所有的庫。
Days4-6
接下來是最難的部分了，我們好不容易向學校的書***說明了問題。然后讓Mark（我覺得他能做Unix管理員完全是因為娶了Dean的女兒）開始學習編譯。***他終于同意交給我來做，因為他什么都不會。在第6天***，編譯工作終于完成了。
我拿出修改之后的代碼，重新開始編譯。一切正常，然后我運行了一下，天吶！這問題又出現了。源代碼分成了15個文件，干擾信息又出來了。簡直跟魔法一樣，我覺得自己被打敗了，問題肯定不在源代碼里。Phelps博士也有點不樂意了，他覺得這么長時間，即使重新寫一個也該完成了。“當然”，我失落地說，“你是對的，說不定重寫比較好。”“好的，我們明天開始重寫。”博士說。
Day7
見鬼去吧，我不會認輸的！我跟Phelps博士說：“你不用付給我錢了，只要給我時間，我一定要找到這個bug。”
Days8-14
我學聰明了，他一定是修改了一些庫，我開始研究編譯出來的匯編（雖然我之前根本就不懂匯編），從開始學習，到***看懂匯編代碼，花了六天。雖然根本沒發現什么異常，完全就是在浪費時間。
Day 15
突然，我意識到，問題可能出在編譯器上，一定是。每次編譯代碼的時候，編譯器就會往源代碼中添加干擾信息。我以前也聽說過這種情況。
啊耶！我找到了！我們也有編譯器的源代碼，我查了一下，謝天謝地，終于找到了。編譯器鏈接器中的代碼是這樣的：
1)檢測所有對fopen（）的調用，在打開的文件中查找Phelps博士的問題，如果找到
2）編譯的時候，重寫15個文件
3）使用這15個文件編譯博士的程序，在鏈接的時候會輸出-o形式的名字
編譯器被這個學生修改了，以便往Phelps博士的程序中添加代碼。
幾天之后，AT&T的技術支持提供了原版的編譯器和鏈接器代碼，我們重新編譯，替換了被修改的編譯器和鏈接器。
但是，問題還沒有解決。編譯器被其他我們沒有的源代碼污染了。這些代碼存在于現在可執行的編譯器中，在編譯編譯器的時候，會加入污染代碼。但是它并不修改/usr/src中的代碼，而是將其復制到一個隱藏文件夾，修改編譯器源代碼，編譯，***刪除隱藏文件夾。AT&T發現這個問題花了好長時間。這個學生修改了編譯器，讓編譯器重新編譯的時候加入污染代碼。***我們不得不從另一臺3B2機器上復制過來編譯器的字節碼文件版本，才終于解決這個問題。
通過編譯器的代碼我們還發現，如果編譯/sbin/login的話會加入一些后門代碼，可以允許任何人使用特定的密碼來登入root。這臺電腦可以通過調制解調器或Tymnet接入。終于，這件事引起了校方注意。
這人真是個天才，不過，也太恐怖了！
其他網友回答
- Bug只在產品中有，開發版本中卻沒有或者不可重現
- bug觸發的幾率很小很小，卻又不能小到可以忽視
- 去改不是你寫的代碼中的bug，原來寫代碼的這家伙已經離職了
- 發生bug的地方是99.9%可靠的庫，是你絕對不會懷疑的地方
- 幾年來很多人嘗試去修改的bug，但是沒有人成功過
- 存在邏輯錯誤的bug，只有在運行一段時間之后才會觸發
- debug需要特定領域的知識，正是你不懂的
- debug的deadline很緊
- Stack Overflow掛了
- 在Stack Overflow上搜索問題，發現有人一年前問了同樣的問題，但是沒有人回答。
- 分號鍵失靈
- 看自己一年以前的代碼，有種“這真他媽是我寫的”的感覺
- 庫沒有文檔
- 客戶又改需求了
- ==寫成了=
- IE（如果你做前端）
- Github merge沖突
- 在錯誤的目錄下 rm -rf
- “My code works, I don’t know why”（這句話不需要翻譯了）
- 開會，開會，開會……作為程序員讓我去死吧
那么，你的噩夢又是什么呢？
