10. 注釋 — 只解釋了「how」卻沒有解釋「why」
入門級的程式設計課程通常會教育學生們寫**前先寫注釋、而且要盡量多注釋。 這種教育的出發點是「多注釋肯定比少注釋好、少注釋肯定比沒注釋好」。可不幸的是，很多的程式設計師把這當成了一種任務，對每一行**都注釋一下。
r = n / 2; // 讓 r 等於 n 除以 2
// 當 r - (n/r) 大於 t 時進行迴圈
while ( abs( r - (n/r) ) > t )
經過這樣的注釋，你否明白了這段**是幹什麼的？的確，我也沒明白。 問題就在於，雖然有大量的注釋，可它們只是描述了**是幹什麼了，卻沒有說明**為什麼要這樣寫。
現在，請看一下我們採用另外一種方式對同一段**進行的注釋:
// 使用牛頓-raphson演算法求n的平方根近似值
r = n / 2;
while ( abs( r - (n/r) ) > t )
這就好多了！也許我們還是不能完全明白這段**的作用，但至少是有了一點方向了。
注釋是用來幫助讀者理解**的，不是用來解釋語法的。 我可以大膽的認為，讀者對for迴圈的工作原理是了解的；所以沒必要寫這樣的注釋：「// 對客戶列表進行for迴圈操作」。讀者不明白的是你的**是做什麼用的，你為什麼要採用這種方式實現它。
9. 干擾
很少有程式設計師能在眨眼之間從一種活動中轉換到程式設計的狀態中。通常情況下，我們更類似於需要慢慢啟動的火車，而不是能突然加速的 法拉利; 我們需要一定的時間才能進入工作狀態，一旦我們進入穩定有效的工作狀態，我們的工作效果和產出會很豐碩。 不幸的是，當思路不斷的被客戶、經理、以及你的同事打斷時，你的大腦很難進入程式設計的狀態。
當我們幹一件事情時，有太多的瑣事需要我們放在心裡，我們需要先放下這個事情，處理那個人事情，回頭又幹這個事情，還不能有差錯。這些干擾會中 斷我們的思路，而重新整理清楚思路又要你花費大量的時間，這是讓人懊惱的、沒有比這更讓人洩氣、讓人有挫折感的過程了。
8. 範圍蠕變（scope creep）
範圍蠕變（scope creep） (也稱作焦點蠕變（focus creep）， 需求蠕變（requirement creep）, 功能蠕變（feature creep），以及其它一些亂七八糟的演變詞語)，指在專案管理裡專案的需求變更失控。 當乙個專案的範圍沒有明確的定義清楚、沒有文件化、不受控時就會出現這種現象。 這通常被認為是一種有負面影響的事情，應該盡力避免。
範圍蠕變通常會把乙個簡單的需求變成乙個複雜驚人的需要大量時間的巨無霸。 那些負責需求調研的傢伙們只需要敲幾下無辜的鍵盤就能把事情變成這樣：
◆版本 1: 顯示這個地區的地圖
◆版本 2: 顯示這個地區的地圖，要三維立體的
◆版本 3: 顯示這個地區的地圖，要三維立體的，而且能夠使用它作為飛行導航圖
乙個本來30分鐘能完成的任務變成了一項要幾百人/天才能完成的超級複雜的系統。更糟糕的是，大多數情況下，需求變更是發生在開發階段 的，這樣一來你需要重寫**，重新回歸，有時要把前幾天才開發的**刪除。
7. 管理者 — 完全不懂程式設計
管理工作不是一種簡單的工作。人是一種讓人很討厭的動物; 我們善變、喜怒無常，我們都自以為天下第一。想讓這樣的一群人都感到滿意和團結，你需要付出像山一樣大的努力。 然而，這並不意味著管理者就可以在對下屬的工作毫不理解的情況下進行管理。 當管理者對我們的工作沒有一點知識概念時，後果只會是需求頻繁變動，不現實的工期，普遍的挫折感（管理者和開發人員）。程式設計師們對此的抱怨相當普遍，這也是產生爭執不合的根源。
6. 寫文件
在說這個條目之前我先承認，我們確實有很多的文件生成工具，但據我的經驗，這些工具都是只適合生成api文件，以供其他程式設計師參考。如果你開發 的軟體是平時人們每天都要用的，你必須要寫一些外行人(例如你的實施，客服等)都能理解的文件手冊。
我們可以很容易的看出，有些事情程式設計師們極不願意去做。 你可以簡單的回顧一下所有的開源專案。 人們百折不撓的對這些專案的乙個索求是什麼：文件。
我敢打保票的說，不管在**，至少會有一半的程式設計師當要求寫文件時會說：「不能讓其他人去寫嗎？「。
5. 程式 — 缺少文件
我可從來沒說過我們程式設計師是說一套做一套的人。 程式設計師們經常會在他們的專案裡用到第三方的類庫和應用。 於是，我們需要文件。 很不幸呀，就像我在第6條裡說的那樣，程式設計師們痛恨寫文件。這戲劇性的事情發生在我們自己身上。
當你需要使用乙個第三方類庫時發現，至少有一半的api無從知道是幹什麼好用的，沒有任何事情比這個更打擊人的了。 函式 poorlynamedfunctiona() 和函式 poorlybutsimilarlynamedfunctionb() 有什麼區別？ 在我使用 propertyx 屬性前是否需要測試一下它是不是 null 值？我估計只有通過自己的測試和報錯才能弄清楚!。
4. 硬體
任何乙個曾經被叫去除錯乙個資料庫伺服器上奇怪的宕機現象，或是被叫去解決raid驅動器不能正確的工作的問題的程式設計師，當發現是硬體問題時， 都會痛苦不已。 人們有一種普遍的誤解，認為程式設計師就是搞電腦的，他們肯定知道如何修理電腦。 不可否認，有些程式設計師確實是個全才，但我估計，絕大部分程式設計師都不知道，或者根本不關心當程式被編譯成機器碼後如何工作的。我們只關心做出來的東西是否符 合需求文件，這樣我們才能集中精力去解決這上層的任務。
3. 含糊不清
「**宕機了」. 「xx功能工作不正常」。 處理含糊不清的任務是種痛苦。 每次當非程式設計師被要求重現他們所遇到的問題時表現出的憤怒都讓我吃驚不已。 他們似乎不太明白，僅僅一句」它宕機了，修復它！」是無法讓我們開始工作的，我們需要更多的資訊。
軟體的執行是(大部分情況下)有跡可尋的。我們也樂見與此。 請遷就我們，幫我們指出是在哪個階段，什麼情況下出的問題，而不是簡單的說一句」修復它「。
2. 其他程式設計師
程式設計師經常和其他程式設計師合不來。詫異嗎，但這是真的。 這方面的事情我可以輕鬆的列出十大條，講細點甚至可以單獨寫篇部落格，所以這裡我只列出幾個常見的、讓其他同事感到懊惱的程式設計師的特徵：
◆脾氣暴躁以至態度極不友好。
◆不能明白什麼時候該去討論系統的架構，什麼時候是應該去動手去做。
◆無法進行有效的溝通，使用易於誤解的專業術語。
◆自己的事情處理不好。
◆對要做的程式和專案缺乏興趣。
那麼，這最後的，但不是最糟糕的，序號為1的讓程式設計師們煩惱的…
1. 自己寫的** — 6個月以後的
don』t sneeze, i think i see a bug.
回顧一下自己以前寫的**，是否也會愁眉苦臉？當時怎麼會這麼愚蠢！怎麼能編寫成這樣的東西！燒掉!丟到火裡！
現實是，軟體技術界是乙個不斷變化的世界。 今天被看成是最好的方式，明天也許就會過時。 我們不可能寫出完美的**，因為判斷我們的程式好壞的標準日新月異。 這令人很不爽，你的作品，今天看來是那麼的完美，但也許不久之後就會變成被人嘲笑的物件了。 真是讓人沮喪，因為不論我們如何努力的學習最新最棒的開發工具，設計，框架，以及開發方法，我們總是比最新的技術發展趨勢慢了一拍。 對於我來說，這是做乙個程式設計師最苦惱的事情了。我們不斷的公升級技術，是為了讓軟體更好，但卻禁不住感到，我就像乙個做沙毯（sand-painting）的和尚。
來自
程式設計師的十大級別
第一級 神人，天資過人而又是技術狂熱者同時還擁有過人的商業頭腦，遠矚，技術過人，大器也。如丁磊，求伯君。第二級 高人，有天賦，技術過人但沒有過人的商業頭腦，通常此類人不是頂尖黑客就是技術總監之流。第 牛人，技術精湛，熟悉行業知識，敢於創新，有自己的公司和軟體產品。第四級 工頭，技術精湛，有領導團隊的...
程式設計師的十大無奈
2 做程式設計師的女朋友幸福不？這個問題記得以前有人問過我女朋友，我當時當場回答那人，我說 做程式設計師的女朋友，不一定幸福，而做我的女朋友呢？絕對幸福 所以說呢，事在人為。3 程式設計師的生活單調不單調？對於生活，我無法用單調這個詞來形容，因為每個人都有自己喜歡的生活，可能我呢，喜歡看書，研究程式...
程式設計師的十大無奈
2 做程式設計師的女朋友幸福不？這個問題記得以前有人問過我女朋友，我當時當場回答那人，我說 做程式設計師的女朋友，不一定幸福，而做我的女朋友呢？絕對幸福 所以說呢，事在人為。3 程式設計師的生活單調不單調？對於生活，我無法用單調這個詞來形容，因為每個人都有自己喜歡的生活，可能我呢，喜歡看書，研究程式...