導讀:要想成爲一個偉大的程序員,須要的可不只僅是可以編寫出能夠正常運行的代碼。Justin James給出了可以成爲業內頂尖高手的程序員應該具備的幾個典型特質。程序員
要想成爲高效的程序員,你須要具有必定的綜合素質纔可以讓你用你所掌握的技能、經驗和知識編寫出有效的代碼。有一些開發人員在技術方面具有必定的技巧,但他們永遠沒法成爲高效的程序員,就是由於他們缺少所需的其它幾項特質。本文將給出成爲一個偉大的程序員所必須具有的7項特質。編程
1. 主動學習新的技術和非技術兩方面的知識學習
很差的程序員只有在實在不行的時候纔開始進行知識學習。良好的程序員會主動學習新的技術知識。偉大的程序員不只會自行學習新的技術知識, 並且還會學習非技術方面的知識,對各類知識來源都有一種開放的心態,而不會象有的人那樣固步自封。網站
具體點說,很差的程序員只有在參加了採用WPF的項目時纔開始學習XAML;良好的程序員一年前就學習了XAML,由於他感受它頗有意思;而偉大的程序員還閱讀了WPF應用程序的設計指南、可用性(usability)理論或者什麼相似的學習課程,於是他可以製做出卓爾不羣的UI。
2. 務實而不教條搜索引擎
嚴格遵照那些不成文的「編程規則」每每是一種奢侈品,沒有多少開發人員可以承受得起。若是大家的規格說明書不是由頂尖的開發人員編寫的,也不是在頂尖的開發人員指導下編寫的, 我就能夠向你保證,你可能也承受不起。編碼
我常常可以碰到一些程序員,他們沒法或者拒絕作某個任務只是由於完成這個任務的作法一般不爲最佳實踐所接受。業務需求不多會受到實現需求所採用的技術的制約;沒有人會說,「這咱們不該該把這個需求寫到規格說明書裏,由於要實現這個需求,程序員就不得不寫一段很臭的代碼。」設計
在結束的那一天,程序員的任務是要生成一個有效的應用程序,而毫不是要求在技術方面達到十全十美。我可不是在爲垃圾代碼作辯護。我想說的是,總會在有些時候,你會寫出一些代碼,這些代碼你永遠不會做爲範例向別人展現作事的正確方法。若是隻有一種寫法,那麼這種代碼就不是糟糕的代碼 —— 但要保證你已窮盡了其它全部可能的方案。
3. 懂得如何經過研究找到答案索引
經過研究找到答案可不只僅只是在搜索引擎中鍵入幾個關鍵字那麼簡單, 也不是到Stack Overflow或者MSDN forums這類網站發個問題帖。我就碰到過在搜索引擎里根本搜不到答案的問題,而後我Stack Overflow 或者MSDN forums裏發的全部問題貼都沒有一個像樣的答案,不過我仍是解決了我所碰到的問題使得工做得以繼續。我不是魔術師 —— 我只是懂得如何找到答案,如何找出問題的根本緣由。開發
有許問題都屬於情景式的問題,若是你依賴於搜索引擎或者論壇,就會在各類連接中浪費大量的時間而最終沒法獲得真正的答案。要學習如何進行根本緣由分析,學習底層系統方面的知識才可以找到其它的線索和解決方案,還要學習若是在對問題有個全局性的認識後纔對其進行深刻分析。
4. 擁有激情產品
不喜歡這份工做,就沒法成爲這個行業中的頂尖高手。卻是也有一些僅僅把編程看成一份普通工做的程序員水平也還不錯,但若是你的三觀就是如此的話,你就不太會願意去作可以將你引向成功的全部事情。這個觀點會使不少傢伙不悅,由於他們會以爲這是一種人身侮辱。「我是一個很好的程序員,但我還有其它重要的事情要作,我不能讓工做成爲我人生的所有。」 我徹底理解;我也有別的更重要的事情。儘管我也痛恨這麼說,當咱們對個人工做熱情高漲之時,我願意(雖然不是渴望)拋棄我其它更重要的事情來首先完成手頭的工做。要說你不肯意全情投入就沒法成爲高手,不算是人身侮辱,這是事實而已。
你的激情不能僅僅只在編程一個方面 —— 你必須在你的工做、你所使用的技術、你的老闆、你的項目等等方面都有激情。 我目擊過一些很是好甚至很偉大的程序員其表現平平,只是由於有一些條件不太合適。好比,他們不喜歡手頭的項目,或者項目中所用的技術讓他們討厭。我曾經就是一個這樣的程序員,我也同這樣的程序員一塊兒共過事。不管從哪一個角度講,我都不喜歡這樣的程序員。若是你發現你的狀況就是如此,就須要當即解決這個問題,要麼挖掘出手頭的工做或項目中有意思的地方從而能讓你調整心情,要麼就不要接着幹了。怪不值當的。
5. 將自負留在門外
許多開發人員都很是自負。僅僅是比有些人聰明、懂得多一點或者經驗更豐富一點,可不是意味着和那些人相比你纔是好人。你要尊重別人,真正聽取並考慮別人的觀點,在須要的時候向他們求助,並且還不能小瞧別人。 你還應該更加關心團隊的勝敗,而不是僅僅關心你在工做中的榮譽得失。
6. 具備企業家的精神
最優秀的開發人員不會是不務正業者。對他們來說,產品的成功不只僅意味着他們的薪水有着落了。由於他們在工做中熱情飽滿,他們是爲了項目有更好的發展而工做,並且會勇往直前。
7. 測量兩次,下刀一次。。。但測量不要多於三次
開發人員可能會犯的最糟糕的錯誤之一就是還不知道要幹什麼呢,就一猛子扎到代碼裏去了。(當他們把這種作法稱做敏捷開發時狀況更爲糟糕,好像用敏捷兩字就能讓狀況好轉似的)。當偉大的開發人員跳進代碼裏去的時候,那是由於需求規格說明同他們之前實現過的某種作法十分類似。偉大的程序員在面臨新問題時,他們會進行思考、計劃和研究。
開發人員當中最最優秀的不會墮入「分析癱瘓者(analysis paralysis)」陷阱。他們懂得要對某些事情當心謹慎(好比涉及錢或我的數據時),只有這些特殊領域才適合我所說的「要測量三次」。任何超過三次的狀況發生就意味着你在浪費你的時間(除非在鮮有的特例中,好比核反應堆、宇宙飛船、對衝基金會計系統)。
在某個特定的時間點就要中止計劃,開始編碼,而後再看看你的計劃在哪些方面須要進行相應的調整,這一點很是重要。順便說一下,這就是我爲何成爲敏捷方法擁躉的緣由之一。我所知道的最優秀的開發人員在計劃再也不合適或者發現計劃有缺陷時,都會願意將計劃放棄掉。