程式設計師最艱鉅的任務跟寫程式碼沒有太多關係。編碼是邏輯思路的一種實踐，這跟程式設計師日常工作中的其它任務比起來相對簡單。如果你認為自己還是個水平一般的程式設計師，在你真正的能進入到高手行列前，請確保你已經克服了下列晉級的障礙。
1. 解釋你在做什麼
解釋軟體開發過程是一件很困難的事情。那些非程式設計師職業的人也許知道很多關於程式設計的事情，但很顯然，他們不會程式設計。對他們來說，我們的生活就是在一間黑暗的房子裡趴在鍵盤前消耗咖啡。
你會在你的朋友、家人和同事中遇到這樣的人，他會認為編碼不是一個正確的職業。
2. 形象的說出軟體解決方案
根據一些簡短的需求－通常是一知半解的，你需要設計出資料結構，軟體架構，程式碼演算法，通訊協議，以及其它所有針對商業問題的解決方案各種組成部分。然後你需要用一種外行人聽的懂的術語將它們表達出來，並需要在規定的時間裡提交給客戶。
很少有程式設計師能做好這些。
3. 評估工期
這是程式設計師痛苦的根源。在開發任務沒有完成之前，你絕對沒有可能確定完成這個任務所需的時間。也許程式跟以前寫的很相似，但環境變了，問題變了，限制條件變了。
經驗會提供一定的判斷力，但大部分的程式設計師都習慣於低估問題難度。這其中的原因是他們只考慮編碼方面的因素，而忽略了這個任務清單上的其它事務。
4. 維護他人的程式碼
針對一個問題可能會有一萬種解決方案，一萬種寫法。接手別人寫的程式碼，意味著你要花無數的時間在成千上萬的程式碼行裡探索，理解當初作者的思路。而且，如果是一個不相信註釋和文件的程式設計師留下的半個項目，麻煩就更大了。
5. 軟體邊界的模糊蔓延和讓人吐血的奇怪功能需求
雖然敏捷開發方法給軟體範圍的膨脹提供了一定的預備空間，但這並沒有起到任何的作用－尤其是當你遇到一些由一時興起的怪念頭產生的功能需求。你知道這樣做必定會失敗。你的團隊知道這樣做必定會失敗。但客戶覺得很好，而當失敗不可避免的出現時，全是你的錯，因為是你沒有理解他們的真實意圖。
6. 在缺少最佳化和過度最佳化之間找到平衡點
複雜的軟體永遠不會做到完美;總是會有一些更好的方案。你完全可以沒完沒了的優化下去，這就是為什麼軟體專案從來都沒有提前完成的。
而另一面，「這樣就行了－我以後會優化它的」這種心態也是常見的。程式碼今天好用，但你知道明天可能會出現麻煩或不能用。當然了，你是不需要去修改它的，它將會留給下一個倒楣蛋程式設計師。
7. 測試你的程式碼
單元測試你也寫了，軟體也提交了測試組，但bug依舊存在…
軟體是複雜的，可能包含成千上萬行程式碼。系統中可能存在百萬的各種互動和邏輯路徑;你不可能完全測試它們。
類似的，軟體會在不同的條件下跟不同的平台上的不同的軟體互動。你不可能所有的都測到。
寫出好的單元測試是一種枯燥且辛苦的工作。理想情況下，測試應該在著手開發前就已經寫好——但你如何向客戶解釋為什麼四個星期過去了仍然沒有可用的軟體?
單元測試並不能覆蓋每個問題點。在理想的世界裡，應該有一個獨立的團隊來寫測驗並且積極的去發現問題。不幸的是，對大多數專案來說，這樣成本太高，時間不夠，於是用開發團隊來寫測試程式。而開發團隊潛意識的會避免很多極端的邊界狀況。
程式設計師喜歡用符合邏輯的方式處理所有問題。但用戶很少是這樣的。他們會發現你永遠意想不到的問題。
8. 寫入軟體文件
寫入程式碼文件是一項費力耗時的工作。很少有程式設計師擅長這個、喜歡這個的，而且很少有程式設計師會花時間去讀它們。
9. 處理IT問題
你每天都在研究技術。你也許是一個HTML或PHP程式設計師，但你很可能會遇到一些例如硬碟損壞、驅動衝突或軟體崩潰的問題。解決這些事情不是你的主要責任，但是，除非你解決了這些問題，否者你將無法繼續你的開發工作。
不幸的是，對於IT圈外的人來說，程式設計師應該是軟硬體都精通的人。當他們遇到了問題，他們自己不花時間就解決，直接找你。不論是遇到什麼問題：你是用電腦的，你一定知道如何將預算表導入Sage，如何配置Oracle，或為何在他們的黑莓手機上發不出郵件。
當然了，這些打攪絕對不能成為你完不成工作的理由，也沒有報酬，不是嗎?
10. 處理人的問題
上面的這些難題都可以總結為「人的問題」。很少有外行人會去建議一個飛行員如何開飛機或建議一個電器工程師如何佈線。但很多人卻會興致勃勃的勇敢的建議如何開發軟體。
我相信對於這些人沒有什麼好辦法。你需要接受這樣的事實：這世界上有一半的智力是低於平均的!
