寫出能夠解決問題的程式碼，或是能夠運用資料結構或演算法，還不足以成為一位頂尖的 程式設計 師！
知名 顧問公司 Conigent 的架構師 Justin James 在美國科技網站 TechRepublic 上發表了 “Seven Traits of Effective Programmers” 這篇文章，列出了能夠成為編程領域中的大師們所具備的七項特質。有趣的是，從 James 的清單看來，想成為傑出的程式設計師，非技術性的特質反而比起技術性特質更重要。
如果你自認在技術方面已經具備了一定的程度與能力，想要邁向「神」級大師的等級，甚至有一天可以像某些矽谷工程師一樣，帥氣的跟客戶說，「想找我寫程式？請找我的經紀人談！」本文或許可以提供你一些不同的啟發，來看看 James 的清單，你是否也覺得這是傑出程式設計師的重要特質？
1. 樂在學習，除了關注新的技術發展，也了解非技術知識的重要性
普通的程式設計師，通常是在需要某項技能時才會開始進行學習；傑出的程式設計師，對於各種知識都保持開放的學習心態，他們了解，技術能力只能在初期讓你保持領先，若想成就卓越的能力就必須用實驗、練習與閱讀來灌溉知識的花園。
舉例來說，普通的程式設計師只有在參與 WPF 專案時，才開始學習 XAML，而傑出的程式設計師則老早就開始進行學習 XAML，因為他們覺得這很有趣，而且除了 WPF 的應用之外，還會進一步涉獵相關的延伸知識，因此，他們總是能夠實作出最佳的解決方案。
2. 務實但不固執
遵守「編程規範 (Rules of Programming)」是一件奢侈的事，也很少有開發人員能夠做到這一點，尤其當「編程規範」不是由專業的程式開發人員所撰寫的，或不是由專業的程式開發人員所指導而產出的規範，因為「不專業的規則」是很難讓人接受的。
我也常常遇到一些無法 / 拒絕執行專案任務的程式設計師，往往只是因為他的想法 / 建議並沒有被接受成為最好的實踐清單上。
程式設計師應該要注意的是： 你的任務，是要實作出一個可以解決問題的方案，而不是產出一個呈現完美技術的藝術品。
3. 真正了解問題之後，再思考解決方案
找問題的答案，可不只是在搜索引擎上輸入幾個關鍵字，或是到 Stack Overflow/MSDN forums 這些論壇上發佈問題帖子詢問其他網友這麼簡單而已。
像我就曾經有過幾次在搜索引擎上搜尋不到想要的答案，或是在 Stack Overflow/MSDN forums 上發佈問題帖子卻沒有人回應我的狀況。
但是，我還是必須設法解決問題，結果也順利都處理完成了。
我並不是魔術師 —— 我只是知道如何尋找答案，以及如何找出問題的根源如此而已。
實務中，有許多的問題是屬於情境式的 (Situational)，你必須像剝洋蔥一樣一層一層的往核心探究下去，如果僅僅只是依賴搜索引擎或者論壇，只是浪費時間而已。
所以，你應該學習如何找出問題根源的分析方法，以及學會對問題有了全面性的認識之後，才進行深入的分析與探討，才能尋得相關的線索與解決方案。
4. 擁有熱情
如果你不喜歡撰寫程式這份工作，就無法成為這個領域裡的頂尖高手，但也有一些「把撰寫程式的工作就當成是工作」的開發人員表現得還不錯。如果你也具有這樣的心態，那麼，這可能會成為你自我突破上的一項障礙。
傑出的開發人員，不會只對撰寫程式擁有熱情，他們對老闆、對專案與對自己所使用的技術都具有同等的喜愛，並且會將這些熱情透過互動感染其他的專案成員。
我在實務經驗中曾經遇過一些能力很好的開發人員，只是因為不喜歡所參與的專案，或是不喜歡專案中所使用的技術，而導致表現平平，甚至我自己也曾經歷過這個階段。
無論從哪一個角度來看，這樣的開發人員都是不受歡迎的。如果你發現你正處於這樣的狀況，就應該試著去發掘出所參與的專案或所負責的工作中，對你別具意義之處，如果都找不到或是仍無法調整心境，或許可以考慮離開這個專案，因為繼續下去對個人對企業而言都是一件非常不值得的事。
5. 把謙虛與目標相結合，才能有更大的影響力
有些開發人員僅僅是比某些人聰明，或是比某些人多一點經驗，就顯得自命不凡。你可以當小廟裡的大和尚 / 小池塘裡的大魚，但，不要因此而忽略了還有更大的廟 / 池塘。
你應該對人保持謙遜，要懂得尊重別人，能夠聽取並包容別人的觀點與想法，在必要時懂得向他人求助，但是，絕對不要小看他人。
另外，你還必須重視與關心團隊的表現，而不是只關心自己在工作中的得失。
6. 具備冒險的精神
傑出的程式開發人員不會是得過且過的人。對他們而言，實踐一個成功的解決方案的意義，遠遠勝過只是視本身的職務為一張長期飯票。主因為，他們將每次的任務都當成是一趟探險，他們期望從中學得不同以往的知識或體驗，也為能讓專案順利進行而勇往直前。
7. 先思考再行動是對的，但，不要忘 記「 過猶不及 」
大多數的開發人員常犯的錯誤之一，是在還沒做好系統分析時就一頭栽入程式語法的規劃中。
然而，傑出的開發人員往往是在他們確定規格書中的要求，與自己過去某段實作系統的經驗相類似，在胸有成竹的情況下才會著手撰寫程式。也就是傑出的開發人員在面臨新的問題時，會先進行思考、計劃和研究，再行動。
而且，傑出的開發人員不會讓自己陷入「分析癱瘓（Analysis Paralysis）」的陷阱中，這是指程式在開發初期，進行系統分析時，常會因為執著於想掌控所有可能的變化與意外，而造成大量時間的浪費，反而因此讓專案停在原地，陷入無止盡的假設中。
他們知道在專案中應該對某些事件要小心謹慎，比如，個人的隱私或是金錢等，但是，若過於謹慎，就是浪費時間了，除非你評估的是像核子反應爐 (Nuclear Reactors)、或對沖基金帳務系統 (Hedge Fund Accounting Systems) 這類具有危及眾人性命或是個人生存條件的系統。
在專案中設計里程碑可以用來檢視進度的狀況是否在規劃的行程中進行，或是有需要做調整的地方，這一點是非常重要的，甚至在必要的時候，寧可放棄或終止整個專案。
參考文獻：
1.李俊宏（1995）。 網頁設計 原則的研究一以大專院校首頁設計為例。雲林技術學院程式設計研究所碩士論文，未出版，雲林。
2.王育民、王怡舜 (1999), 行銷策略導向之旅館業網際網路服務內容規劃與設計, 第五屆服務管理研討會, 台北市, .
3.林隆儀、林岳民 (2005), 廣告比較策略與廣告訴求方式對購買意願的影響-產品涉入之干擾效果, 企業管理學報, 65(), 1-30.
資料來源：buzzorange
PIECE2巨群
文章定位：
