程序員最艱巨的任務跟編寫代碼沒有多少關系。編碼是邏輯思路的一種實踐，這跟程序員日常工作中的其它任務比起來相對簡單。如果你認為自己還是一個水平一般的程序員，在你真正能進入到高手行列前，請確保你已經克服了下列晉級的障礙。

　　1. 解釋你在干什么

　　解釋軟件開發過程是一個很困難的事情。那些非程序員職業的人也許知道很多關于編程的事情，但很顯然，他們不會編程。對于他們來說，我們的生活就是在一間黑暗的屋子里趴在鍵盤前消耗著咖啡。

　　你會在你的朋友、家人和同事中遇到這樣的人，他會認為編碼不是一個正確的職業。

　　2. 形象地說出軟件解決方案

　　根據一些簡短的需求——通常是一知半解的，你需要設計出數據結構，軟件架構，代碼算法，通信協議，以及其它所有針對商業問題的解決方案的各種組成部分。然后你需要用一種外行人聽得懂的術語將它們表達出來，并需要在規定的時間里提交給客戶。

　　很少有程序員能做好這些。

　　3. 評估工期

　　這是程序員痛苦的根源。在開發任務沒有完成之前，你是絕對沒有可能確定完成這個任務需要的時間。也許程序跟以前寫的很相似，但環境變了，問題變了，限制條件變了。

　　經驗會提供一定的判斷力，但大部分的程序員都習慣于低估問題難度。這其中的原因是他們只考慮編碼方面的因素，而忽略了這個任務清單上的其它事務。

　　4. 維護他人的代碼

　　針對一個問題可能會有一萬種解決方案，一萬種寫法。接手別人寫的代碼，意味著你要花無數的時間在成千上萬的代碼行里探索，理解當初作者的思路。而且，如果是一個不相信注釋和文檔的程序員留下的半個項目，麻煩就更大了。

　　5. 軟件范圍的模糊界定和讓人吐血的奇怪功能需求

　　雖然敏捷開發方法給軟件范圍的界定提供了一定的預留空間，但這并沒有起到什么作用——尤其是當你遇到一些由一時興起的怪念頭產生的功能需求。你知道這樣做必定會失敗，你的團隊知道這樣做必定會失敗，但客戶覺得很好。而當失敗不可避免地出現時，全是你的錯，因為是你沒有理解他們的真實意圖。

　　6. 在缺少優化和過度優化之間找到平衡點

　　復雜的軟件永遠不會做到完美，總會有一些更好的方案。你完全可以沒完沒了地優化下去，這就是為什么軟件項目從來都沒有提前完工的。

　　而另一面，“這樣就行了，我以后會優化它的”這種心態也是常見的。代碼今天好用，但也許明天可能就會出現麻煩或不能用。當然了，你是不需要去修改它的，它將會留給下一個倒霉蛋程序員。

　　7. 測試自己的代碼

　　單元測試你也寫了，軟件也提交了測試組，但bug依舊存在……

　　軟件是復雜的，可能包含成千上萬行代碼。系統中可能存在百萬的各種交互和邏輯路徑，你不可能完全測試它們。

　　類似的，軟件會在不同的條件下跟不同的平臺上的不同的軟件交互。你不可能所有的都測到。

　　寫出好的單元測試是一種枯燥且辛苦的工作。理想情況下，測試應該在著手開發前就已經寫好。但你如何向客戶解釋為什么四個星期過去了仍然沒有可用的軟件?

　　單元測試并不能覆蓋每個問題點。在理想的世界里，應該有一個獨立的團隊來寫測試并積極地去發現問題。不幸的是，對大多數項目來說，這樣成本太高，時間不夠，于是一般是開發團隊來寫測試程序。而開發團隊潛意識地會避免很多極端的邊界情況。

　　程序員喜歡用符合邏輯的方式處理所有問題。但用戶很少是這樣的，他們會發現你永遠意想不到的問題。

　　8. 寫軟件文檔

　　給代碼寫文檔是一項費力耗時的工作。很少有程序員擅長這個，喜歡這個，并且很少有程序員會花時間去讀文檔。

　　9. 處理IT問題

　　你每天都在研究技術。你也許是一個HTML或PHP程序員，但你很可能會遇到一些例如硬盤損壞、驅動沖突或軟件崩潰的問題。解決這些事情不是你的主要責任，但是，你又不得不先解決了這些問題，否則你將無法繼續你的開發工作。

　　不幸的是，對于IT圈外的人來說，程序員應該是軟硬件都精通的人。當他們遇到了問題，他們自己不花時間去解決，直接會找你。不論是遇到什么問題：你是用計算機的，你一定知道如何將預算表導入Sage，如何配置Oracle，或為何在他們的黑莓手機上發不出郵件。

　　當然了，這些干擾絕對不能成為你完不成工作的理由，也沒有報酬，不是嗎?

　　10. 處理人的問題

　　上面的這些難題都可以總結為“人的問題”。很少有外行人會去建議一個飛行員如何開飛機或建議一個電器工程師如何布線。但很多人卻會興致勃勃地勇敢地建議如何開發軟件。

　　對于這些人沒有什么好辦法。你需要接受這樣的事實：這世界上有一半的智力是低于平均水平的!