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