如何成為傑出的程序員或軟體工程師？
怎樣的程序員才算優秀的程序員，他應該具備有哪些素質。
我不能算是一個很優秀的程序員，但這個問題我已經反覆思考了五年了。跟大家分享一下我的看法：
首先， 我認為答案絕對不是 "只要寫很多年代碼就好了「。我面試過不少有10年經驗，代碼卻寫的很糟糕的程序員。經驗很保貴， 但只靠經驗是不夠的。就像下棋一樣，假如你用心研究，複習，不斷挑戰自己，也許可以成為一名大師。但不斷用懶散的方式去玩棋，下20年也只是一個"臭棋簍子「。
我覺得比較有用的進步方式：
1. 學會看代碼
大多數程序員都只願意用自己寫的代碼，但高手一般可以輕易調用別人寫的代碼。表面看上去是工作習慣不同， 但實際上是能力上的差別。看代碼要比寫代碼難很多倍。
我建議上班時多給隊友們作code review，下班後試著閱讀github上的開源代碼。
2. 複習
程序員一般都很忙， 手上有永遠也做不完的活兒。但在某些公司里， 你只是在反覆做同樣的事。偶爾放下手上的活兒，留下一部分時間來分析自己的弱點，更改壞習慣，看新書， 或學習新語言。
3. 做個人項目
工作中的編程一般只能讓你熟悉一部分技術， 導致漏洞的形成。這就好像你長期一個人在自己後院練習投籃， 但第一次打比賽才（在慘敗中）發些原來還需要傳球， 防守， 強籃板這些概念。
Facebook喜歡僱傭所謂的 「full stack programmer」，就是一個人從設計，到交互，到html， css，javascript， server，sql， 架構，和數據統計都能做。成為full stack programmer最好的方式就是不斷做個人項目。
4. 問答網站
問問題和回答問題都是很好的學習方式。 有的時候寫出一個好問題， 比寫出解答次問題所需要的代碼還難。寫問題可以幫你整理自己的思維邏輯。你可以試著每周在http://stackoverflow.com上問一個好問題或寫一個好答案。
5. 加入一個好團隊
最好的進步方式就是跟比自己強的人一起做事。高手都願意聚在一起，所以很多會選擇去優秀的早期創業公司。我在矽谷和創新工場創業時遇到了很多神人， 跟他們學了不少東西。
原作者： Nick Dellamaggiore, 基礎架構組工程經理
2015年2月3日
作為一名工程經理，我經常被同事和面試人問「作為一個Coursera工程師，我的職業生涯發展是什麼？」儘管有些人更希望成長為經理，但我發現還有很多人對如何成長為獨立貢獻者（ individual contributor）更有興趣。
所有在Coursera工程師共享同樣的名稱：「軟體工程師」。你可能會認為這會導致模糊的職業發展，但我們相比嚴格的等級，更喜歡這種模式，理由如下。
我們是一個小的，緊湊的工程組織下的創業公司，我們專註於一起工作，共同實現我們的使命：為全世界提供最好的教育而奮鬥。每個人在沒有被人為組織結構，職稱和角色所羈絆下去發揮其最大的潛能。
我們的文化體現著謙遜。傑出的工程師認可是被公認的貢獻，領導力和態度，而不是他們的頭銜。
每個人都是領導者。我們的文化是非常開放的，包容的;一些最好的想法，往往來自剛畢業大學生或實習生。我們渴望幫助每個人在這裡成長為技術帶頭人。
作為技術人員，我們正不斷努力改善我們的技能，幫助我們的工程師不斷提高。我們希望在這裡的工作，是我們自我變革的體驗，並以同樣的方式去改造公司的軌跡。
為了指導我們的工程團隊，我們列出由一些傑出高產的工程師都體現的品質列表。這些都是我們在Coursera，以及其他矽谷高科技公司同行，如LinkedIn，谷歌和Facebook所欽佩的優秀素質。我們分享這個列表，並希望激發其他工程團隊去思考他們看重的素質，以及如何建立，培養和獎勵優秀人才的企業文化。
如何成為一個偉大工程師
結果驅動
偉大工程師產生了偉大成果。 Coursera重視工程師從開始設計，實施到交付一系列環節。這裡的原因：
對於任何重大項目，往往是在細節中出問題。比如產品推出，運營服務，產品功能。在交付和運營的服務或產品上體現主人翁意識，這是我們的核心價值觀。
結果會直接給業務增值。我們認為一個員工的貢獻累計來自於如何衡量增加的價值。影響力可以來自於很多維度，包括增值，活躍度，收入，工程效率，網站穩定，可擴展性等等。顯著影響力在交付MVP（最小核心價值產品）很少能夠實現。在我們搭建的產品和需求中不斷的迭代才能最大化我們的價值。
我們的指導方針是「有效爬坡」的原則，我們讚賞能夠平衡執行速度，編寫可擴展組件和代碼質量。我們也看重「10倍工程師」，即不僅能快速提供高質量的結果，同時也激勵和指導別人更聰明地更快的工作。
領導力
領導者不一定是一個管理者。技術領導是說的你的工作方式。你把你的項目，團隊，整個技術組服務好。最好的工程師顯示至少其中的一些特質：
項目領導：偉大的工程師們可以從不同的項目中擔任技術負責人的角色，項目的範圍從小到大，影響力從低到高。他們能駕馭好點子，闡明設計，排除阻礙，不斷改進。他們跟產品組合作確立正確的產品上線順序，他們知道在質量，完成度和速度如何權衡考慮。有時他們通過數據驅動決策保證項目完成。
找出差距：偉大的工程師們能夠廣泛地思考面臨的差距和問題。更重要的是，他們是第一次去發現我們從來不知道我們有的問題。他們更看重解決問題而不是抱怨 - 事實上，他們渴望保持手勤，用創造力和真正的熱情應對面前的挑戰。
「向上看齊」：偉大的工程師們往往圍繞比他們更好的工程師。他們是以身作則提高生產力，領導和激勵他人。他們通過代碼和設計評審來作為導師幫助大家。
愛學習：偉大的工程師為了不斷提高技能，他們熱情地閱讀技術文檔，研究論文，和博客。他們喜歡上課，吸收別人的經驗。
組織存在感：偉大的工程師在整個組織中傳承知識和經驗。他們通過技術講座，讀書分享，Hack大賽去分享他們的工作。一個偉大的工程師可以在外部發表博客文章，會議演講，或發表研究論文。
影響力：偉大的工程師影響其他工程師採用新技術，架構，流程和標準。這可以通過他們能影響到的工作空間距離或者代碼審核隊列的大小來衡量。
態度：像所有Coursera的員工，優秀工程師們關心隊友和保持謙卑。他們認識到，每一個錯誤其實是有機會讓他們做的更好。
技術卓越
偉大的工程師在技術上的優秀體現在很多方面：他們可以是厲害的產品黑客，演算法高手，注重細節的基礎架構工程師，或以上所有。我們重視在設計解決方案時深入思考，考慮複雜的產品和基礎設施問題的工程師。
偉大的工程師設計是強大的，直觀的，可擴展的，靈活的，可維護，可操作性，可擴展性和高效的。他們努力質量和執行速度之間實現平衡。
權衡
除了業務目標的貢獻，偉大的工程師通過提高工程團隊的工作效率，構建可重用的組件，提供工具，使代碼庫更好管理這些都能整體性提升工程組織。這意味著構建抽象的服務或組件，使它們成為多個產品的需求或提高開發人員的生產力。這也意味著主動去構建工具，提取函數庫，修復破碎的窗戶，編寫工程文檔，或測試用例。
這不是一個清單！
偉大的工程師不一定擅長在上面列出的所有領域，但必須擅長一些。他們可能是非常全面的，或者在少數項目上極其突出。像下面的遊戲人物，你不大可能就像塞西爾（左）全面高分;但你可能更像哥拉斯（右）更加均衡。
在Coursera我們怎麼使用這個列表？
我們在內部表揚一些體現了這個標準中可以表率的工程師。
獨立貢獻者使用這個文件來追蹤他們事業上的進步，我們都添加註釋，故事和例子，以便其他人可以了解誰做了了不起的事情。
在Coursera工程經理使用此文檔對團隊成員在1：1會議，和績效考核中去反饋評價。
任何人當他們看到其他人做很棒的事情都可以直接說出來。這可以在發生在 1:1 (兩個人的會議)，全組大會，技術部大會，通過Slack頻道（企業通訊工具），或通過電子郵件。
最後的話
在Coursera，我們為全世界提供最棒的教育資源。我們想把高質量的教育，不再只提供給精英，而是公平的環境。同樣，在我們的工程組，我們想創造一個讓每一個工程師能夠實現偉大的環境。我們提倡透明制度和包容性，並提供質量為導向的這份列表，來幫助工程師繼續改進。
以下內容摘自博文「編程巨星的唯一秘訣」，
中文翻譯在此：
http://www.aqee.net/the-singular-secret-of-the-rockstar-programmer/
不是什麼複雜的道理，不是什麼難懂的理論。不是具有什麼天賦或「編程超能力「才能做到的事情。最終成為的是一個優秀的程序員還是一個很爛的程序員，這跟你的出身一點關係都沒有。
而真正的原因只有一個，唯一的一個：
對所做的事情的理解越深，你就會做的越好。
超級程序員跟那些平庸的、一般的程序員比起來，對自己要做的事情的理解要深的多的多。這就是原因。
37條來啦——條條通往自由之路
成為傑出程序員，意味著你將獲得諸多自由：
財務自由，時間自由，心靈自由。
誰不嚮往自由——
然而，自由的一面是必要的約束，比如下面你會讀到的軟體工程師能力自我評價表（37條）。
軟體工程的奠基人之一瓦茨.漢弗雷總結說，軟體領域可以分為兩個方面：一方面是技藝創新的大爆發；而另一方面是堅持不懈的工程工作，包括軟體的改善、維護和測試等，這一方面佔了90%-95%的比例。（詳見軟體故事 第三章）絕大部分軟體工程師都不是技術天才，但卻都可以通過堅持必要的約束（訓練），成為傑出的程序員（軟體工程師）。
最近我們出版的這本書構建之法——現代軟體工程得到諸多好評，比如：
請看：《構建之法》試讀 （多看版已上線：構建之法【下載 在線閱讀 書評】）
書中第三章的主題是「軟體工程師的成長」 ，作者鄒欣老師結合中國軟體行業的特點，歸納出在中國IT行業「好工程師」的要素，並做成一個自我評價清單：
現代軟體工程 課件 軟體工程師能力自我評價表（37條）
1.保持高標準，不要受制於破窗理論(broken windows theory)。
[i]
當你看到不靠譜的設計、糟糕的代碼、過時的文檔和測試用例的時候，不要想「既然別人的代碼已經這樣了，我的代碼也可以隨便一點啦。」
2. 主動解決問題。當看到不靠譜的設計，糟糕的代碼的時候，不要想「可能別人會來管這個事情」 ，或者「我下個月發一個郵件讓大家討論一下」。要主動地把問題給解決了。
[ii]
3. 經常給自己充電，身體訓練是運動員生活的一部分，學習是軟體工程師職業的伴侶。每半年就要了解和學習一些新的相關技術。通過定期分享（面對面的分享，寫技術博客等）來確保自己真正掌握了新技術。
4. DRY （Don"t Repeat Yourself）——別重複。在一個系統中，每一個知識點都應該有一個無異議的、正規的表現形式。
5. 消除不相關模塊之間的影響，在設計模塊的時候，要讓它們目標明確並單一，能獨立存在，沒有不明確的外部依賴。
6. 通過快速原型來學習，快速原型的目的是學習，它的價值不在於代碼，而在於你通過快速原型學到了什麼。
7. 設計要接近問題領域，在設計的時候，要接近你目標用戶的語言和環境。
8. 估計任務所花費的時間，避免意外。在開始工作的時候，要做出時間和潛在影響的估計，並通告相關人士，避免最後關頭意外發生。
9. 圖形界面的工具有它的長處，但是不要忘了命令行工具也可以發揮很高的效率，特別是可以用腳本構建各種組合命令的時候。
10. 有很多代碼編輯器，請把其中一個用得非常熟練。讓編輯器可以實現自己的定製，可以用腳本驅動，用起來得心應手。
11. 理解常用的設計模式，並知道擇機而用。設計模式不錯，更重要的是知道它的目的是什麼，什麼時候用，什麼時候不用。
12. 代碼版本管理工具是你代碼的保障，重要的代碼一定要有代碼版本管理。
13. 在debug的時候，不要驚慌，想想導致問題的原因可能在哪裡。一步一步地找到原因。要在實踐中運用工具，善於分析日誌（log），從中找到bug。同時，在自己的代碼裡面加 log.
14. 重要的介面要用形式化的「合同」來規定。用文檔和斷言、自動化測試等工具來保證代碼的確按照合同來做事，不多也不少。使用斷言 (assertion) 或者其他技術來驗證代碼中的假設，你認為不可能發生的事情在現實世界中往往會發生。
15. 只在異常的情況下才使用異常 (Exception), 不加判斷地過多使用異常，會降低代碼的效率和可維護性。記住不要用異常來傳遞正常的信息。
16. 善始善終。如果某個函數申請了空間或其他資源，這個函數負責釋放這些資源。
17. 當你的軟體有多種技術結合在一起的時候，要採用松耦合的配置模式，而不是要把所有代碼都集成到一起。
18. 把常用模塊的功能打造成獨立的服務，通過良好的界面 (API) 來調用不同的服務。
19. 在設計中考慮對並行的支持，這樣你的API 設計會比較容易擴展。
20. 在設計中把展現模塊 (View) 和實體模塊 (Model) 分開，這樣你的設計會更有靈活性。
21. 重視演算法的效率，在開始寫之前就要估計好演算法的效率是哪一個數量級上的（big-O）。
22. 在實際的運行場景中測試你的演算法，不要停留在數學分析層面。有時候一個小小的實際因素 (是否支持大小寫敏感的排序，數據是否支持多語言)會導致演算法效率的巨大變化。
23. 經常重構代碼，同時注意要解決問題的根源。
24. 在開始設計的時候就要考慮如何測試 ，如果代碼出了問題，有log 來輔助debug 么? 儘早測試，經常測試，爭取實現自動化測試，爭取每一個構建的版本都能有某些自動測試。
25. 代碼生成工具可以生成一堆一堆的代碼，在正式使用它們之前，要確保你能理解它們，並且必要的時候能debug 這些代碼。
26. 和一個實際的用戶一起使用軟體，獲得第一手反饋。
27. 在自動測試的時候，要有意引地入bug，來保證自動測試的確能捕獲這些錯誤。
28. 如果測試沒有做完，那麼開發也沒有做完。
29. 適當地追求代碼覆蓋率：每一行的代碼都覆蓋了，但是程序未必正確。要確保程序覆蓋了不同的程序狀態和各種組合條件。
30. 如果團隊成員碰到了一個有普遍意義的bug, 應該建立一個測試用例抓住以後將會出現的類似的bug。
31. 測試：多走一步，多考慮一層。如果程序運行了一星期不退出，如果用戶的屏幕解析度再提高一個檔次，這個程序會出什麼可能的錯誤?
32. （帶領團隊）了解用戶的期望值，稍稍超出用戶的期望值，讓用戶有驚喜。
33. (帶領團隊) 不要停留在被動地收集需求，要挖掘需求。真正的需求可能被過時的假設、對用戶的誤解或其他因素所遮擋。
34. （帶領團隊）把所有的術語和項目相關的名詞、縮寫等都放在一個地方。
35. （帶領團隊）不要依賴於某個人的手動操作，而是要把這些操作都做成有相關許可權的人士都能運行的腳本。這樣就不會出現因為某人休假而項目被卡住的情況。
36. （帶領團隊）要讓重用變得更容易。一個軟體團隊要創造一種環境，讓軟體的重用變得更容易。
37. （帶領團隊）在每一次迭代之後，都要總結經驗，讓下一次迭代的日程安排更可靠。
[i] 參見：Broken windows theory
[ii] Jim Barksdale 是Netscape 公司的CEO, 他提出了Snake Rule，見到問題，就要解決問題，但是也不要沉溺於無法挽回的事情中。參見：MenkBlog 以及 Jim Barksdale Said It
附：
什麼才是程序員的核心競爭力？
有哪些可以提高程序員技術檔次的書或博客？
作為一個帝都碼農，現在的處境很迷茫，不知道未來在哪裡，我該怎麼辦？
我覺得成為一個傑出的程序員最重要的是"創造性「，比如：
他不時有好、新穎的想法出現，並且具備能把這些想法變成現實的能力；
對於一般人習以為常的例行工作，他能想出更好更有效的方法方式去完成，他弄出來後，別人才感嘆：這麼簡單，我怎麼想不到呢？
……
至於代碼寫得漂亮，學習能力強，掌握多種編程語言，對技術理解透徹等等，那也是他的特徵，但並不足以讓他成為」傑出「的程序員。
另外，」傑出「不」傑出「，是看他己經做出的事，不是看他能做出的事。
我來回答後一個問題，關於薪水的。
----------------------------------------------------------------
如果你是個優秀程序員，挑大樑的，實際上，你一個人給足夠的時間，你就可以完成完整的一個項目。從設計到實現到測試到發行。書上說軟體工程，說teamwork沒錯，但是優秀的程序員是從頭到腳啥都能幹，都能幹好的。能挑大樑，老闆高薪保你一個人的忠誠度就可以保證技術團隊的穩定，其他人都是外圍，replaceable，所以他們只能拿零頭，你服不？
從一個方面，這樣的人離職帶走的就不是一個模塊，而可能是整個產品線。尤其是中小企業，傷不起啊，所以高薪是必然的。股權也是可以考慮的。拿得比所有經理多，你服不？
就算是大點的項目，優秀的程序員做上層的設計，功力稍微有一點不同，就可以造成整個項目開銷上巨大的區別。高薪是值得的。在架構設計上節約錢，老闆除非腦子進水。來了牛人，直接節省開支100萬，發50萬獎金，你服不？
還有的程序員本身是博士出生，可以搞研究，兼具科研能力，直接搞定公司的核心技術壁壘。他們高薪你服不？要不就是跨專業的，跨度大，達到很奇葩以至於公司做某個項目時候非他不可，高薪，你服不？
...
-------------------------------------------------------------------
參照 Quora 的答案：優秀的與偉大的軟體工程師（似乎我們都說成程序員）的區別是什麼？ Software Engineering: What distinguishes a good software engineer from a great one?
第一名 2500+ 票：
- 能夠平衡實用與完美。 Able to balance pragmatism and perfectionism
- 不怕調試和修復BUG。 Not averse to debugging and bugfixing
- 健康的懷疑態度。 Healthy skepticism
—— Russel Simmons, former CTO Co-founder, Yelp
第二名 1500+ 票：
1. 這不關於他們寫了的代碼，而關於他們沒必要寫的代碼；
2. 這不關於他們代碼庫增長有多快（依據於代碼的行數或複雜度），而關於他們怎麼將代碼庫縮小同時不丟失功能或特性；
3. 如果你嘗試去跟他們爭辯「什麼編程語言才是最好的」， 他們是微笑、又或者對這個厭倦，然後轉移話題么？或者，他們布教么？如果他們布教，那他們不是一個偉大的工程師；
4. 這並不關於那些代碼或編程語言，也不關於他們的痴迷、技藝、天賦、或其它虛假的魔法形容詞。最簡單地，他們是否在代碼之上的層面了解軟體？他們是否在架構層面明白軟體？還是說他們只能去想代碼的行數？他們可以在抽象的數學問題和軟體之間切換么？他們可以跟利益相關者一起工作並理解那些人對系統的需求，或者他們會不會開發一個他們想要開發的系統——他們認為你真的想要這個？一個人可以成為一個偉大的駭客或編碼者或程序員，但那與一個偉大的軟體工程師不一樣。我並沒有使用一個價值量表，一個偉大的程序員也是一個偉大的程序員……但是你不能要求一個焊接工去建一座橋。
5. 他們能否「發現缺陷盲點」，當房間里其它所有人都正迷戀於一些解決方案或新玩意時？此外，還能解釋這些基礎的缺陷點、讓房間里**所有的人**都對這個缺陷點有清晰的認識？
6. 他們能否傾聽？如果他們不能，那他們不是一位偉大的軟體工程師。
原第二名 340 票：
- 有天分 Talent
- 自律 Discipline
- 有經驗 Experience
- 有商業意識 Business-awareness
- 有社交意識（合作意識） Social-awareness
—— Slava Akhmechet, Founder at RethinkDB
# 更新於2015-03-25
原來第二名被排到好後面去了，雖然票數從193票上升到340票
如果你的目的是想做一個優秀的架構師，而不是把主要目的放在如何設計一個讓用戶【覺得】優秀的產品，那我覺得你只要在學習區裡面持續不斷地練習就好了。
成年人的思想還能進步么？ ? 學而時嘻之
最近看了一些關於程序員的職業發展思考的文章，然後聽了場公司一個寫了10年代碼的程序員的培訓，工作後也和蠻多的程序員合作過,程序員的自我修養如何修鍊，才能有比較好的職業發展路徑，站在PM的角度談下自己的想法僅供參考：
1.事情做得專業的前提是能關注到細節
我覺得細心謹慎是程序員最基本的修養和素質，邏輯能力啥的倒是更為上一層的事情。整天想好的演算法和架構是沒有用的，你知道當你跟產品經理說解了半天的bug是因為少了個分號的時候，產品經理心中鄙視的是多麼的波濤洶湧么。
如果連這些代碼基本的細節都不能注意的話，談何其他呢
2.尊敬每一個人就像尊敬代碼一樣
很多程序員是傲嬌的，覺得產品就是自己做出來的，其他的人都是輔助的。所以很多程序員心裡是看不上產品，測試的，也就造成很多溝通障礙。
首先上面這種人一定一輩子只能寫代碼，哪怕技術再牛。
我不太認同寫代碼只能寫到30歲，但是程序員30歲之後，要想有更大的發展，那麼做團隊管理，要麼做技術諮詢，才能讓自己的能力和積累的經驗擴大化，那麼這個時候，卓越的溝通能力往往成為關鍵。
3.用經驗堆砌出你的產品技術全局觀
這個就涉及到架構方面，產品經理提出需求，不僅僅想聽到的是這個需求可以做還是不可以做這麼簡單，而是如果可以做，那麼開發成本是怎樣的，會對目前的系統產品模塊造成哪些影響，有哪些的risk，如果不可以做，有沒有好的替代方案或者簡化方案。
如果在需求評估的時候，PM可以得到這些答案，一定會跪舔你的
當然，另一方面，如果在前期評估中，這些都沒有想到的話，後期造成的種種後果也是需要程序員自己承擔的。
4.做好情緒管理
理論上，程序員都是冷靜的。但是現實中，情緒衝動的也是蠻多的，我不知道這樣的性格會對寫代碼有何影響，但是因為情緒影響了判斷就不好了，例如因為需求反覆修改就索性說這個代碼實現不了這種事情，終究會對自己的信譽造成很大影響的。這種事情我經常遇到。。。
5.技術要做到精益求精
編程語言那麼多，多語言的程序員雖然搶手，但是如果是半瓶水的水平，估計也是沒人願意要的。
現在程序員非常多，是因為這個行業入門的門檻非常低，也就造成行業的水平參差不齊。做一個網站很難么，找個現成的框架，懂點資料庫，建個數據表，前端再找個現成的模板，修修改改一個網站就出來了。
但是滿足這樣就完了？那麼水平可能永遠就是這樣了，其實這其中每一個點都是可以研究的很深的，比如網站的大數據存儲，如何提供程序並行運行的效率，，未來計算機行業的技術分工會越來越細，任何一個方面的專家都是相當有用的
6、職業規劃，其實你沒的選
聽一個前輩講，自己也對職業也很迷茫過，後來索性去創業了，但是失敗的一塌糊塗，最後才明白，自己最會的還是寫代碼，最懂的還是Java，有時候其實你沒的選
7.Stay hungry ，Stay Foolish
技術是永無止境的，好的程序員必須保持對於新的技術敏感度，保持學習的熱情
同時看書學習可以更多的得到思維模式，可以在最快的時間發現問題的所在
如果沒有好的思維模式，很多程序員遇到需求了，先百度，看看有沒有相似的代碼，遇到bug再去百度下，看看別人是怎麼解的，這種永遠只是碼農而已
聽說一本好的程序書籍至少要讀12遍才能理解。。。
想要成為一名傑出的程序員或者軟體工程師要知道以下幾點：
關於編程學習
1.編程和程序設計99%來源於自學。你有在學校的python課上面學到現在要用的嗎？當你真正接手一個項目，工作會逼你重新學習一遍的。
2.你可以在任何年齡學習編程（反正現在書店都有C++的幼兒習題集了）。
3.五年之後，你現在掌握的大多數編程知識都會過時。
關於編程語言
1.千萬不要在意你用的編程語言，比選擇語言更加重要的是解決你所面對的問題。
2.沒有別的語言比你現在所使用的更好了，當然這不是說你可以一直用你現在所使用的語言。要記住，對於程序員來說，效率是生命。選擇一個效率最高的語言可以更快的幫你完成那些事。
關於編程
1.沒有任何事情比一個BUG更加討厭了，尤其是一個愚蠢的BUG。當你花了一周時間尋找錯誤最後發現你的變數少打了一個字母或者是少打了一個符號，你失去的不只是一周的時間，還有無數工作的激情。這裡有4種調試技巧可以幫你快速定位錯誤：
還在斷點調試？教你四種調試技巧讓你快速定位錯誤！2.你寫的越多，你就越能體會到下一步你的程序能做什麼和你能做什麼。當你看著那些「菜鳥們」得意洋洋的樣子，你就會發現當初的自己是多麼的狂妄和愚蠢。
3.編程一點都不性感，嘗試帶一個女孩回家然後在床邊告訴她你英勇的拯救了一個部門的工作，原因是他們的伺服器崩潰，你去修復了它，並且讓伺服器的效率提高了三倍。然後回來告訴我女孩的反應。
4.一定要寫注釋！不寫注釋你一個月之後就會忘記當時你要幹啥！（我是誰？我在哪？我幹嘛要寫這段話？）
5.少即是多。簡介明了的設計語句可以幫助他人和自己更好的去理解。
最後打點雞血
1.編程雖然一點都不性感，但是它可以讓人著迷於此。當你無數次打開一個APP或者一個網頁，腦中想的都是如何實現的問題，那麼你就開始沒法想像離開了編程的生活。
2.編程可以變得十分有趣，前提是你徹底理解了它。
3.在編程中，你會感到失落也會感到迷茫。但是，這是每一個程序員都經歷過的過程，而且這個過程可能會重複很多次。不忘初心，我們的目標是改變這個世界 
歡迎關注我的微信公眾號：九章演算法（ninechapter）,回復」乾貨」可以提取更多程序員技術乾貨，教你如何學習演算法知識、如何應對面試、如何成為一名優秀的程序員。
回答你問題的可以說大多都不是傑出的程序員，傑出是一個很難界定的概念，我所理解的傑出，你首先得在你所工作的環境中體現出你的不可替代性，也就是說某件事情離開了你還真就搞不定了；其次是你所創造的效益要高於身邊的大部分同事；再就是你能給周圍的同事帶來實質性的幫助。也就是說溝通能力、解決問題的能力都是需要很棒才行的。
註：我想你是不是把程序員和工程師的概念搞混了，程序員再傑出畢竟是程序員，現在做軟體都是需要講團隊、講人性、講用戶體驗的了。要稱得上「傑出」，絕對不是因為懂得多少，而是實現了什麼樣的成就，傑出的工程師之所以傑出，是因為有傑出的成就，不是他/她懂多少東西。
傑出的成就必是因為滿足了某方面的需求，把學問和實際聯繫起來，這才是學問的價值所在。
這麼說就清楚了吧，要達到傑出，要做出點像樣的東西來，只是看書學習是不足夠的，去做吧！
不斷的思考，是進步的必要條件
既然題主說到「傑出」，而不是「優秀」，我就較點真。
如果你寫了一段很牛逼、很安全，全世界幾乎無人能找到漏洞的代碼幫人洗錢，算不算傑出的程序員？
如果你寫了一個能應付同時上億次並發的網站，但是沒人喜歡你的產品，算不算傑出的程序員？
如果你用一套弱爆了的系統搭了一個頁面，促進了社會對貧困地區兒童健康狀況的關注，算不算傑出的程序員？
我覺得優秀的程序員應該具備的素質：
1、讓客戶或leader省心——功能盡量做的人性化，注意細節合理性。不要別人提一個問題，才改一個問題。
2、規範的操作習慣、良好的文檔書寫習慣——如果不規範，調試改來改去，會做很多無用功、返工。大問題搞不定還可以了解，總犯低級錯誤就讓人吐血了。
3、解決問題的能力和創新能力！——這個是程序員的核心競爭力！
怎麼達到？
多思考、多做項目、多總結、多觀察....看到好功能，研究下怎麼實現的
Junior - &> Senior 從考慮數據結構和演算法實現 ——&> 程序安全、可維護、效率的轉變。
想成為一個優秀的軟體開發人員,在今天,你該怎樣發展你的職業生涯?這個是我總結的優秀程序員必備十大習慣。按照這些技巧和規則,你可以改善你的現狀,由一個普通的程序員,成為一名優秀的程序員。
學會學習
就算是你有了10年以上的程序員經歷,你也得要不斷地學習,因為你在計算機這個充滿一創造力的領域,每天都會有很多很多的新事物出現。你需要跟上時代的步伐。你需要去了解新的程序語言,以及了解正在發展中的程序語言,以及一些編程框架。還需要去閱讀一些業內的新聞,併到一些熱門的社區去參與在線的討論,這樣你才能明白和了解整個軟體開發的趨勢。
掌握多種語言
程序語言總是有其最適合的領域。當你面對需要解決的問題時,你需要找到一個最適合的語言來解決這些問題。比如,如果你需要性能,可能C/C++是首選,如果你需要跨平台,可能Java是首選,如果你要寫一個Web上的開發程序,那麼PHP,ASP,Ajax,JSP可能會是你的選擇,如果你要處理一些文本並和別的應用交互,可能Perl, Python會是最好的。所以,花一些時間去探索一下其它你並熟悉的程序語言,能讓你的眼界變寬,因為你被武裝得更好,你思考問題也就更為全面,這對於自己和項目都會有好的幫助。
理性面對不同的操作系統或技術
程序員們總是有自己心目中無可比擬的技術和操作系統。只有一部分優秀的程序員明白不同操作系統的優勢和長處和短處,這樣,在系統選型的時候,才能做到真正的客觀和公正,而不會讓情緒影響到自己。同樣,語言也是一樣,有太多的程序員總是喜歡糾纏於語言的對比,如:Java和Perl。哪個剛剛出道的程序員沒有爭論去類似的話題呢?比如VC++和Delphi等等。爭論這些東西只能表明自己的膚淺和浮燥。優秀的程序並不會執著於這些,而是能夠理性的分析和理心地面對,從而才能客觀地做出正確的選擇。
別把自己框在單一的開發環境中
再一次,正如上面所述,每個程序員都有自己忠愛的工具和技術,有的喜歡使用像VC++一樣的圖形界面的調試器,而我更喜歡GDB命令行方面的調式器。等等等等。程序員在使用什麼樣的工具上的爭論還少嗎?到處都是啊。使用什麼樣的工具本來無所謂,只要你能更好更快地達到你的目的。但是有一點是優秀程序員都應該了解的——那就是應該去嘗試一下別的工作環境。沒有比較,你永遠不知道誰好誰不好,你也永遠不知道你所不知道的。
使用版本管理工具管理你的代碼
千萬不要告訴我你不知道源碼的版本管理,如果你的團隊開發的源代碼並沒有版本管理系統,那麼我要告訴你,你的軟體開發還處於石器時代。趕快使用一個版式本管理工具吧。使用什麼樣的版本管理工具依賴於你的團隊的大小和地理分布,你也許正在使用最有效率或最沒有效率的工具來管理你的源代碼。但一個優秀的程序員總是會使用一款源碼版本管理工具來管理自己的代碼。
做一個優秀的團隊成員
除非你喜歡獨奏,除非你是孤膽英雄。但我想告訴你,今天,可能沒有一個成熟的軟體是你一個人能做的到的,你可能是你團隊中最牛的大拿,但這並不意味著你就是好的團隊成員。你的能力只有放到一個團隊中才能施展開來。你在和你的團隊成員交流中有禮貌嗎?你是否經常和他們溝通,並且大家都喜歡和你在一起討論問題?想一想一個足球隊吧,你是這個隊中好的成員嗎?當別人看到你在場上的跑動時,當別人看到你的傳球和接球和搶斷時,你的團員成員能因為你的動作受到鼓舞嗎?
把你的工作變成文檔
這一條目當然包括了在代碼中寫注釋,但那還僅僅不夠,你還需要做得更多。有良好的注釋風格的代碼是一個文檔的基礎,他能夠讓你和你的團隊容易的明白你的意圖和想法。寫下文檔,並不僅僅是怕我們忘了當時的想法,而且還是一種團隊的離線交流的方法,更是一種知識傳遞的方法。記錄下你所知道的一切會是一個好的習慣。因為,我相信你不希望別人總是在你最忙的時候來打斷你問問題,或是你在休假的時候接到公司的電話來詢問你問題。而你自己如果老是守著自己的東西,其結果只可能是讓你自己長時間地深陷在這塊東西內,而你就更本不可以去做更多的事情。包括向上的晉陞。你可能以為「教會徒弟能餓死師父」,但我告訴你,你的保守會讓你失去更多更好的東西,請你相信我,我絕不是在這裡聳人聽聞。
注意備份和安全
可能你覺得這是一個「廢話」,你已明白了備份的重要性。但是,我還是要在這裡提出,丟失東西是我們人生中的一部份,你總是會丟東西,這點你永遠無法避免。比如:你的筆記本電腦被人偷了,你的硬碟損壞了,你的電腦中病毒了,你的系統被人入侵了,甚至整個大樓被燒了,等等,等等。所以,做好備份工作是非常非常重要的事情,硬碟是不可信的,所以定期的刻錄光碟或是磁帶可能會是一個好的方法,網路也是不可信的,所以小心病毒和黑客,不但使用軟體方面的安全策略,你更需要一個健全的管理制度。此外,盡量的讓你的數據放在不同的地方,並做好定期(每日,每周,每月)的備份策略。
設計要足夠靈活
可能你的需求只會要求你實現一個死的東西,但是,你作為一個優秀的程序,你應該隨時在思考這個死的東西是否可以有靈活的一面,比如把一些參數變成可以配置的,把一些公用的東西形成你的函數庫以便以後重用,是否提供插件方面的功能?你的模塊是否要以像積木一樣隨意組合?如果要有修改的話,你的設計是否能夠馬上應付?當然,靈活的設計可能並不是要你去重新發明輪子,你應該儘可能是使用標準化的東西。所謂靈話的設計就是要讓讓考慮更多需求之外的東西,把需求中這一類的問題都考慮到,而不是只處理需求中所說的那一特定的東西。比如說,需要需要的屏幕解析度是800×600,那麼你的設計能否靈活於其他的解析度?程序設計總是需要我們去處理不同的環境,以及未來的趨勢。我們需要用動態的眼光去思考問題,而不是刻舟求劍。也許有一天,你今天寫的程序就要移植到別的環境中去,那個時候你就能真正明白什麼是靈活的設計了。
不要搬起石頭砸自己的腳
程序員總是有一種不好的習慣,那就是總是想趕快地完成自己手上的工作。但情況卻往往事已願違。越是想做得快,就越是容易出問題,越是想做得快,就越是容易遺漏問題,最終,程序改過來改過去,按下葫蘆起了瓢,最後花費的時間和精力反而更多。欲速而不達。優秀程序員的習慣是前面多花一些時間多作一些調查,試驗一下不同的解決方案,如果時間允許,一個好的習慣是,每4個小時的編程,需要一個小時的休息,然後又是4個小時的編碼。當然,這因人而異,但其目的就是讓你時常回頭看看,讓你想一想這樣三個問題:1.是否這麼做是對的?2.是否這麼做考慮到了所有的情況?3.是否有更好的方法?想好了再說,時常回頭看看走過的路,時常總結一下過去事,會對你有很大的幫助。熱愛，強烈的熱愛！
上面這些回答說這麼多，其實我覺得只在於你的核心競爭力，也就是不可替代性有多強。
讀別人的代碼。
如果你沒有看過webkit,linux,glibc,gcc,llvm,binutils,gdb,hotspot,v8，裡面60%以上的代碼，永遠都不是。
推薦閱讀：