軟體開發是一個挺不錯的工作，不過同時也像任何其他工作一樣有著不好的一面。這裡列出了大部分程式設計師對於寫程式碼無法忍受的 10 件事。
對於非程式設計師來說，他們的工作看起來非常幸福。需求很高、待遇很好，公司提供各種各樣的補貼福利等等。然而實話實說，雖然以上所說都不為虛，這份工作就像其他任何工作一樣充滿了讓程式設計師們抓狂地扯下僅存的幾根頭髮的煩惱。一天當中可以有好幾件事能把一個普通程式設計師逼迫到處於崩潰的邊緣。
基於來自線上論壇裡真實程式設計師們的評論和投票，請這 10 個程式設計師最感到沮喪的事。如果看過之後，你還對成為他們的一員執迷不悟的話，請別說沒有被警告過哦。
10、硬體
如果沒有了賴以生存的硬體，軟體當然是什麼也幹不了的。儘管一些程式設計師願意去忽略硬體端，但他們不可避免地或早或晚會在搭建或者除錯程式時面對硬體特定性的問題。這就是為什麼有些程式設計師，強烈建議新程式設計師們熟悉他們程式碼之下底層的硬體和系統，來減少未來類似問題的惡化。
網友的遭遇：
“任何一個曾經被呼叫來除錯一個詭異的資料庫伺服器崩潰，或是為什麼 RAID 驅動程式沒有正常工作的程式設計師，都知道處理硬體問題是多麼痛苦。” Steve Borthwick
“程式設計師痛恨硬體：因為他們不能總是指責硬體。” 匿名
9、一坐一天
除非你有一個跑步機功能的辦公桌，軟體開發的工作基本不是一個有氧健身活動。大部分程式設計師長時間坐著，彎腰駝背地操作著鍵盤，目不轉睛地盯著電腦螢幕。所有這一切只需一會兒就會變得不舒適。如果你不至少換換在哪裡坐著，這也能變得非常壓抑。
網友的遭遇：
“坐在一把椅子上一整天並且盯著螢幕。一段時間之前毛病開始了。一開始是背，然後是脖子，接下來眼睛開始灼傷疲勞，腦袋開始疼…人開始坐立不安…即便我開始用健身，打太極、瑜珈、氣功、騎自行車去上班。我也不能再每天八個多小時這樣坐著了。一整天困在辦公室裡…看著太陽朝升夕落，卻仍然坐在那把傻了吧唧的椅子上虛度光陰。” Markus Toman
伯樂線上推薦閱讀：《程式設計師的常見健康問題》。
8、除錯程式
即使是最好的，最小心翼翼打造出來的程式碼也免不了錯誤。自然而然的，開發者們必須經常地花費時間追蹤並且修復軟體的 Bug；不管源自自己的程式碼還是別人的 。有些錯誤能被迅速發現並修復，其他的隱藏得太深，可能會令人發狂，進而導致浪費了數小時寶貴的開發時間，更別說因此損失的碼農的理智了。
網友的遭遇：
“發現一個難以重現的 Bug，甚至更糟，一組相同的程式碼在整合測試中隨機地通過或失敗！之後你就會感覺你可能永遠也不會發現那些神祕潛伏在某處著的惡魔程式碼。WTF！” Emmanuel Ngwane
“我們寫出瞭如此龐大的程式（甚至有時很小的程式），以至於當除錯過程中我們去睡覺之後，我們遺忘了當初的錯誤是什麼。” Ayush Bhatnagar
“除錯程式，特別是當你在一個包含了上千行程式碼的大專案裡工作時，大多數的極客（比如我）傾向於用一個投影儀來除錯。因為我們的眼睛會舒服多了。”Isaac Perez
“Heisenbugs /海森堡(不確定原理)。”Awal Garg
7. 拙劣的文件
與其他開發者的程式碼共事可能令人沮喪。不過如果程式碼至少有個清晰的文件，那就不會那麼的令人討厭。不幸的是實際情況不總是這樣。那些註釋蹩腳，亦或是缺少文字描述如何工作的軟體，想要除錯、增進、或者整合這些軟體所需要的時間大大延長。更進一步來說，這對程式設計師的血壓更是有害無益。
網友的遭遇：
“最令人沮喪的事就是被僱傭來為一個文件拙劣的軟體工作。這使得接受的人舉步維艱。它們缺少註釋，有著糟糕的程式碼語義，尤其是當前面的程式設計師們留下了一大堆缺陷和錯誤。”Angel Angeles III
“理解某個白痴寫的沒有文件沒有註釋的程式碼。” Abhishek Chauhan
“我跟絕大多數程式設計師一樣，大部分時間花在了維護缺乏文件的程式碼上，而不是編寫新的程式碼。” Walt Karas
伯樂線上推薦閱讀：《從程式設計師到專案經理（29）：怎樣寫文件》
6. 整合程式碼
原始碼控制系統，比如 Git 或 Subversion，是使得多個開發者同時操作同一份程式碼的絕佳工具，避免了大家互相掣肘。可是，最終程式碼的改變需要提交到版本庫裡。此時衝突可能發生，比如說兩個程式設計師修改了相同的檔案或者子程式。在這些情況下這些修改需要被整合起來。有時整合這些衝突可以很快就解決，有時就沒有這麼樂觀了。
網友的遭遇：
“我討厭整合，因為這就好比，你想這麼改程式碼，我想這麼改程式碼。那麼我們到底怎麼改呢？我總能找到一個辦法合併我們所有的修改。但是如果真的存在一個直接衝突，這將會變成一個尷尬的過程。”Jessica Su
“整合衝突純粹是惡魔。” Koustuv Sinha
5. 不切實際的期望
軟體開發者通常被認為是相當聰明的傢伙。不幸的是，這常常導致老闆們，專案經理們，還有銷售人員對程式設計師/程式設計師團隊，可以合理地在一個確定時間點之前的產出有著不切實際的期望。因而誇大了可以交付的成果。這反過來可以導致開發者被榨乾並且引發了碼農們普遍不滿。
網友的遭遇：
“你的老闆對你和你的同事有著極高的期望，但卻遠遠沒有哪怕接近於期待的時間和資源。” Kevin Sekin
“專案經理或者業務分析師們許諾了一個月亮給客戶。然後程式設計師們無論如何被迫得去做出來。” Ratnakar Sadasyula
“我特別喜歡當某個人問了個看似無關緊要的問題，然後就隨隨便便地拋下了一個需要電腦科學領域進步幾十年才能滿足的特性的時候。”Vladislav Zorov
4. 別人破壞了我的程式碼
每一個開發者的程式碼在某一刻都必須與其他開發者所寫的程式碼協同工作。不論是同一個軟體的不同部分，還是第三方軟體庫或工具，還是另一個完全的應用。沒有哪個開發者的程式碼是座孤島。不幸的是，這意味著一個程式設計師的程式碼可以通過輕率、糟糕的溝通、或者僅僅是簡單的疏忽大意，破壞了另一個程式設計師的程式碼。這能引起緊張、壓力、以及更常見的詛咒。
網友的遭遇：
“我經歷的最令我沮喪的事，是和別人一起寫一個程式。他擅自更改了我們二人都連線使用的工具庫，而沒有告知我工具庫已經被修改。這意味著我在呼叫著缺少或者增加了引數的子程式，或者更糟糕的情況裡，程式碼會在我沒有許可權的工具庫裡崩潰。” Sheri Fresonke Harper
“當你的部分程式碼因為別人改變了程式碼而停止工作時。常見的情況是他們的函式使用了比之前更多的引數，有時候程式被完全移除了或者放到了另一個位置。” Jessica Su
“時常被迫退回重改幾天前寫的現在突然損壞的程式碼 （第N次），因為更大的系統被某人修改了（沒有跟你討論）。他要麼沒有進行測試，要麼不介意測試失敗了。你聽到的第一句話就是‘你的程式碼有問題。’” Simon Hayes
3. 非技術人員不懂我的心
儘管軟體開發者的數量與日俱增，更不用提我們日常所需的一切都愈發依賴著軟體。很多非技術背景的人仍然不理解軟體開發者到底在做什麼。對於非技術背景的人們來說，開發者們就是一群“技術人員”。很少有人關注，比如說那些開發軟體和開發硬體的人的區別。這些隨處可見的誤解和錯誤的期待，尤其是來自家庭和朋友，可以真的逼瘋一個程式設計師。
網友的遭遇：
“非技術人員的一個常見誤解就是，既然程式設計師整天和電腦打交道，那我們一定知道怎麼修理電腦。這就好比：邁凱輪車隊簡森·巴頓知道如何拆解和組裝一個賽車齒輪箱，僅僅因為他會開 F1 賽車。” Steve Borthwick
“嗯，我是寫程式碼為生的。但我幫不了你的列印問題或者打不開一個附件或者筆記本無法開機。除非你願意請我一頓午飯或者一瓶啤酒。那麼也許我能幫上忙。” Phil Johnson
“要給人們解釋我可不是在街角開一個店，給他們安裝盜版作業系統和軟體到電腦上的人。” Anbalagan Jeyabalachandran,
“家人朋友們認為你可以搞定任何和電腦有千絲萬縷聯絡的問題。不管是硬體還是軟體。他們才不關心。你最終變成了聽他們奚落。比如‘，如果你連我的 DVD 盤都修不好，那你算什麼軟體工程師。’” Jazib Babar
“1% 到 2% 的人知道你真的在做什麼。” Yasin Pekşen
2. 缺少時間
像其他大部分費勁的事一樣，打造好的軟體需要時間。不幸的是，又像大部分費勁的事一樣，上層管理層與/或客戶經常不願意為了一個理想的解決方案正確實施而長時間地等待。結果軟體開發者經常被逼著把某件事快點搞定。這將導致醜陋的做法、技術債，並且缺少文件。這些都會在未來引發問題，特別是那些將來要被迫面對這些程式碼的程式設計師們。
網友的遭遇：
“我想把事情做好。但是對於把事情快點做完，按熟悉的方法做有著巨大的壓力。有時這是常理之中。但這感覺如今的程式/商業文化已經偏向那個方向太多了。” Tikhon Jelvis
“對我來說這就像賽跑一樣，寫出來我稱之為拼湊程式碼的程式碼，然後在生產中意識到我真希望當初寫得更優雅一些。這裡面有一個持續的時間壓力…” Gene Sewell
“當你做了許多你甚至不認為和好的程式設計習慣沾一點邊的事情時候，這是因為快比質量更為重要。你必須照著被要求的去做。” Jose Palala
“從來沒有時間和金錢去找到正確的解決方案，但是又足夠去找到臨時應急的粗製濫造方案。這一切一遍又一遍地重複著。” Romi Awasthy
1. 和別人的程式碼一起工作
作為一個軟體開發者，或早或晚，你都將與別人的程式碼一起工作。不管是繼承自工作中前輩的遺留程式碼，還是第三方API，還是技術顧問寫的程式碼，你不可能完全逃離被迫著去修改、改進、或者/以及整合別人的程式。更不用說被逼著做經常導致開發者扯下一些或很多青絲的事。
網友的遭遇：
“最糟糕的部分就是被迫去瀏覽別人的程式碼，搞明白、除錯好、反覆調整。更糟糕的是，如果這個寫程式碼的人已經離開了公司，而你當真沒有任何相關的知識遷移。” Ratnakar Sadasyula
“嘗試去解密上千行沒有註釋的程式碼。” Simon Zhu
“我處理過好幾次顧問們寫得一塌糊塗的程式碼。”Joe Samson
“另一個我覺得能令人沮喪的問題是第三方的API。你如此仰賴它們。有時你注意到一個問題，或者需要一個新特性，但那個 API 沒有給出任何原始碼去修改。因此你得去友好地問問 API 的作者，然後盼望最好的結果。” Kevin Sekin
“語言和框架的 Bug。你花了幾天琢磨為什麼你的程式碼不能工作。結果只發現原來你觸發語言或者框架本身的 Bug。” John Paul Alcala
“忍著看那些一群遠遠沒有達到應有水準的人所寫的程式碼。” Nani Tatiana Isobel