曾經遇到過的最噁心的bug：

Bug只會出現在生產環境中，而且無法在本地重現或者觸發

Bug出現的機率雖然很低，但並不足以忽略掉它

Bug出現的原因和競態條件（race condition）有關，這隻會在系統低負載時才出現

Bug出現的真正原因還未知

出現bug的程式碼並不是你編寫的，但是你要負責修復它；寫那段程式碼的人已經不在公司了

導致出現bug的是某個庫，而這個庫在99.9%的情況下都是可靠的。這是你解決該問題所剩的最後一塊陣地了。

多年以來有許多人試圖除錯它，從沒人成功過。

Bug會產生一個邏輯錯誤，而且只會在系統運行了很長一段時間後才會出現

除錯需要你瞭解某個特定的領域知識，而你對那個領域卻一無所知

解決bug的最後期限非常緊，時間不多了

不能忽略這個bug，因為你的飯碗能否保住就看它了

想象一下在地球上透過光脈衝訊號除錯火星探測器上的一個競態條件是多麼令人噁心的一件事，更絕的是隻有在火星的大氣條件下當行星開始對齊時才會發生。這一切都是因為某個從NASA離職多年的人所編寫的庫中生成的嵌入式程式碼出現了一些微妙而深奧的問題所導致。你必須儘快解決這個問題，因為下一次行星對齊就快開始了，而幾百萬美元的專案資金面臨打水漂的風險。

不，我所說的這一切從未發生過。但是看了上面那些你難道不想從橋上跳下去嗎？:)

Jarmo Dee 的回覆

上面那些都不算啥。碼農最糟糕的噩夢是有一個不合格的、非技術出身的專案經理，把時間點定的非常緊，而且總是想掌管一切。

Colin Song

需求變更，恩，是再一次變更。

Jim Bobrien

老闆決定修改產品定位的方向，而且認為所有的修改都會很簡單，並且在沒有和技術團隊溝透過的情況下就向客戶做出了種種承諾。哦，對了，還有需要支援IE瀏覽器。

Lalit Jain

同樣的程式碼週五還跑的好好的，週一就不行了 :D

Shivam Sarawagi

Internet Explorer （如果你是Web開發者）

Jorge Lrun

到StackOverflow上提問，看到1年前有人發過和你準備問的一模一樣的問題，但是沒有任何回覆..

Ben Joseph

Stack Overflow訪問不了！

•你的程式碼意外對某人造成了傷害。

•因特網瀏覽器——如果你是網頁開發工程師的話。

•需求變化——又一次。

•GitHub合併程式碼時出現衝突。

•不小心在錯誤的目錄下執行了rm -rf *命令。瞬間一無所有：（

•堆疊溢位向下溢位！

•即將出現堆疊溢位現象，上網求助的時候看到一個別人發的帖子，問的問題和你想解決的一模一樣，急忙點進去看，卻發現這個帖子已經貼了一年了，至今無人解答。

•達到堆疊溢位的問題限制。

•錯誤在生產實踐中才發現，無法被複制或是觸發。

•錯誤出現的機率很低，但是又沒低到可以忽略的程度。

•錯誤原因包括僅在輕負載情況下出現的競態條件。

•找不到錯誤原因。

•導致錯誤的程式碼並不是你編寫的，但是你要負責程式碼的修復工作；而原始碼的程式設計人員已經辭職不幹了。

•造成錯誤的問題是有些庫在99.9%的時間裡都執行穩定，而錯誤卻藏匿在最不可能發生的地方。

•明明屬於硬體錯誤，但是每個人都以為是軟體的問題。

•多年以來有許多人都想將它除錯好，但是無人成功。

•錯誤屬於邏輯錯誤，在運行了很長一段時間以後才被發現。

•除錯需要某一領域的專業知識，而你對此一無所知。

•通知你修復錯誤的最後期限，時間非常緊張。

•錯誤無法被忽略，因為你的工作正處於緊要關頭。

•分號鍵不管用了。

•一年以後看到自己曾經寫的沒做註釋的程式碼，一臉的懵逼：“臥槽，這特麼我寫的？”“臥槽，我特麼咋寫的？”這感覺就好像在自己的屋子裡迷路了一樣。

•庫里居然沒有檔案。

•過度自信、缺乏準備、準備不足。

•“我的程式碼居然能正常執行，可為毛能執行？！”

•向下溝通：程式設計師需要了解他們正在程式設計的東西到底是什麼，以及應該如何使用。你需要建立程式碼的上下文，因為當你構建某些東西的時候，會有大約100個不同的點需要你作出判斷。建立上下文有助於你進行判斷。

•向上溝通：開會，開會，開會……這能把程式設計師熬死。

•如果客戶和你有時差，你還得多等一天才能和客戶進行確認。

•沒有檔案，甚至更糟糕——有檔案，但壓根沒用。

•格式混亂，導致你由於結構不合理，無法除錯程式碼。

•作業系統的特定版本中出現錯誤，而你沒有訪問權，導致該程式停止響應。

•老闆總想用老版本測試該程式。

•客戶犯二肆意操作，導致程式無法正常執行。你根本不知道客戶到底都幹了什麼，而你的上司則希望你第二天就修好它。