在外行人眼裏，軟件開發工作就跟看天書一樣難——但是程序員往往會一臉苦哈哈地表示“還有更難的呢！”
簡直就是分分鐘秒殺，精神分裂啊！！！
1. 設計解決方案
任務：給出一系列要求，設計出可實施的方案，包括設計數據和代碼結構、功能算法和應用程序流程。
難點：確保你設計的解決方案得滿足客戶的要求，並且按時完成。
網友的話：
“如何始於此終於彼可謂是最難的部分了。”——misconfiguration
“過於臃腫的設計會崩潰，過於淺薄則沒有用。”——nvteighen
“不去一個個試一試，就不知道什麼樣的方案才適用……。”——jpkotta
2. 寫測試
任務：編寫單元測試，以確保每一部分代碼都能正常運作。這些測試不但有助於在開發早期找出 bug，還能方便後續的迴歸測試。很多開發方法論甚至鼓勵我們在寫代碼之前就可以先寫好測試程序。
難點：選擇和編寫測試的過程是既辛苦又繁重的，有時候會讓人感覺是在做無用功。
網友的話：
“我就是不喜歡寫測試，你能怎麼滴。”——Anonymous
3. 編寫文檔
任務：創建用於解釋代碼和應用程序的文檔，包括獨立文檔和代碼註釋。目標人羣範圍從終端用戶乃至其他開發人員。
難點：很耗時間，甚至有時候你會覺得要是沒人看的話那不就是在浪費時間。
網友的話：
“Shit！！！就因爲這是“進程”的組成部分，我們就得寫這些可能根本沒人會去看的文檔。”——Christian Dechery
“通過文檔，我們不需要閱讀代碼就能知道其作用。”——Raghu Nandan
“簡潔又能清晰闡述的文檔，我的大愛啊！”——Ayush Goel
4. 實現自己並不認可的功能
任務：不管什麼原因，如果你的客戶或者上司堅持某個特性和功能，那麼你就不應該將個人的感情因素帶到工作中去。
難點：摒棄個人想法和意見，竭盡全力地實現或支持功能需求。
網友的話：
“……當然你也可以堅持己見然後提早退休，呵呵。”——Sabbir Asgar
5. 關於別人家的代碼
任務：維護、調試或改善由其他開發人員寫的應用程序或者代碼片段。
難點：理解前任開發人員的代碼是非常痛苦的一件事，特別是如果此人已經離開，而他的代碼寫得亂七八糟、缺少必要的註釋和文檔，那就更悲劇了。
網友的話：
“沒文檔的代碼就像後媽。”——Omar Diab
“應該淘汰掉那些不會好好寫代碼的程序員……”——Nani Tatiana Isobel
“代碼破萬行，沒有註釋也不怕不怕了。”——Simon Zhu
6. 和其他人打交道
任務：收集客戶需求，提供狀態管理報告，配合測試人員，和其他工程師協作。
難點：需要向非技術人士解釋技術問題，不得不依賴於其他人交接過來的任務，與 QA 或其他開發人員出現意見相左情況的處理方式。
網友的話：
“交代機器幹事比交代人去做要來得容易得多。”——Marko Poutiainen
“三人行，必有我師焉……合作也是學習的機會。“——Anonymous
“……和外行人說話簡直就像對牛彈琴。” ——lnostdal
“總是要等其他團隊完成任務之後我們才能開工，太拖我們的後腿了。”——Anonymous
7. 預估項目工期
任務：項目一開始，就需要估算出完成所需要的時間。
難點：哪怕沒有接觸過項目，手頭只有模糊的需求說明也得硬着頭皮預估時間。
網友的話：
“在開工之前，真的很難估算出會出現多少亂七八糟的問題……”——Jan Christian Meyer
“我發現估算時間可能是最難的部分了，因爲很多人會將其當做一個承諾，信守着一諾千金。” ——Samnang Chhun
“……每次碰到這個問題我就一個頭十個大……”——Jack Menendez
8. 解釋我的工作
任務：向非程序員——親朋好友，解釋自己的工作內容。
難點：親人和愛人不瞭解我們是做什麼的。總是被要求去解決任何與計算機有關的問題（比如修電腦）。
網友的話：
“總是要跟人解釋——我，不是，修電腦的。”——Brandon P-Lost
“不止一遍地和我的家人說明，我到底是幹什麼的。”——Utsav Singh Rathour
“編程的世界，外行人不懂。”——Anand Safi
“爲什麼別人都認爲我是給電腦安裝盜版操作系統和其他盜版軟件的傢伙呢？我幹什麼了我，我只是程序員。”——Anbu Jey
9. 命名
任務：爲變量、過程、函數、類、對象、數據庫組件等命名。
難點：即使是一個小程序，也會有很多需要命名的東西。名字最好一貫又簡潔，有內涵，能承載一些意思——這個是什麼或者這是用來做什麼的。
網友的話：
“想啊想啊想名字，想出一個好名字~”—— Aditya Muraletharan
“別煩我，我正在給函數命名呢。”—— Lakshman Siripurapu
“計算機科學中只有兩座大山：緩存失效以及命名。”——Phil Karlton