有幾個人在 React 大會上向我請教一個問題——如何成為一名更優秀的程式設計師。人們將我視為一名非常資深的程式設計師，因此值得聽聽我的建議。我覺得可以分享一下，自己多年來在編程方面的「思維模式」。
先簡要自我介紹一下：我叫 James Long，今年 32 歲，有超過 10 年的豐富工作經驗。不過，直到近幾年，我才對自己的工作越來越有信心。即使現在，我還是不斷懷疑自己。關鍵是這種感覺不會消失，所以試著忽略它，繼續深究技術知識，繼續積累經驗。
我再次提醒一下，這些只是提高你技能的幾點建議。最終，你需要弄清楚自己適合的方式是什麼。
找到能激勵你的人，但不要崇拜他們
過去許多年，我仰慕過許多人，並且通過他們關注新技術。我相信他們是正確的，並且對他們所做的事情深入研究，因此學到很多。
這些人往往非常高效、才華橫溢，並且能鼓舞人心。你要想盡辦法找到他們，讓他們激勵和指導你。
不過，別崇拜他們。如果僅看 twitter 上的貼子，你會覺得他們遙不可及。但是，如果走近他們的真實工作中，你會發現自己與他們相比沒什麼不同。只不過在到處摸索嘗試而已，我們都只是在進行試驗。
最後，不要盲目地相信他們。如果你有不同意見，就請他們參與進來，並從觀點碰撞的過程中汲取經驗。
我的一些最有成效的對話就是這樣發生的。曾經，我的 Emacs 配置一團糟。不知道為什麼，我的 OCaml autocompletion 不能用了（它壞了一個多月）。我沒有自動化的東西，有時必須在 shell 歷史中尋找所需的命令。為修復問題，我一開始寫 ugliest 代碼。我將東西寫成全局對象，直到最後才明白我到底做了什麼。
最有經驗的程式設計師一直在破解和鑽研；最重要的是，你能完成任務，達成目標。
不要貶低自己的工作
程式設計師小白往往認為他們的工作價值不大，因為他們是新手。或者你可能是一名有經驗的程式設計師，但是在一個新領域工作，這會讓你感到不爽。但在我看來，最好的想法往往來自於新程式設計師，他們可以看到現有技術的改進點，而思維固化的人卻看不見。
不管怎樣，你的工作都是值得的。最壞的情況是，即使你的想法沒有成功，社區也可以從中了解到為什麼這種方法行不通。
（給社區的一個提示：這要取決於我們是怎麼做的，並讓新人很容易融入進來。）
不要因為害怕落伍而不停工作
每天都會有新技術問世，如果你一晚上不碰技術，可能就會感覺跟不上這個世界。這不是真的。事實上，如果經常放下手頭工作，你會做得更好，因為你會有新想法。
我發現，當不工作的時候，我總會有新想法不斷產生。
實際上，網絡上每天發布的內容大多是「新瓶裝舊酒」，真正具有革命性的技術每隔幾年才會出現一次。關於這個問題，你可以看看這個視頻—— Hammock Driven Development 。
忽略 fluff
客觀上說，你能取得更快進步的主要方法之一是忽略那些並不能提高技能的「fluff」。換句話說，要「聰明的利用時間」。一天的時間有限，你需要將時間花在鑽研更深層次的事情上。隨著時間的發展，你會發現自己有很大進步。
那什麼是「fluff」？這取決於你自身的具體情況。但是，我可以給你一些我認為是「fluff" 的例子：語言語法、庫 API 和配置構建工具。例如，學習一個新的 ES7 JS 語法並不會讓你成為一個更好的程式設計師，這就像學習編譯器是如何工作的一樣。同樣，採用一個實現相同想法卻使用新 API 的新庫也沒多大意義。當然，這些事情很重要，但我建議你花更多時間學習更深層次的概念。這些概念可以讓你終生受益匪淺。
我有個問題想問你：你是否花費大把時間讓代碼看起來很漂亮？如果是這樣，我建議你不要太關注這樣的事。不管怎樣，隨著時間發展，你的代碼會有很多改變。
最好將注意力集中在你試圖解決的核心問題上，比如仔細考慮一下你的抽象層。在完成所有這些工作後，你可以花點時間來改進代碼。這也適用於 DRY 原則（Don』t Repeat Yourself，不要寫重複的代碼）。不過別那麼擔心，隨意複製粘貼吧。
深入學習過去的研究成果
如果你有一個新想法，就會感到很興奮，情不自禁地想坐下來馬上行動。但是，你不應該這樣做，你應該先做一些粗略研究，了解前人是如何解決它的。碰到類似情況時，先花幾天時間研究一下，最終會徹底改變我們解決問題的方式。
學會閱讀學術論文是一項很寶貴的技能。我對 denotational、operational 等語義一無所知，所以我看不懂很多論文。但是，有很多論文使用代碼而不是數學公式來闡述問題，因此並不會太難讀。過去 30 年來，有大量的知識通過論文發表出來。如果你善於獲取這些信息，你很快就會成為思想領袖。
Prettier 是一個佳例。我知道自己想要的是什麼，但不知道如何實現它。做過一些研究後，我發現這篇論文，再過幾天後，我就知道怎麼做了。我在一周內就把主體工作全完成了。如果忽略別人的研究成果，那我就要花更長時間。
如果你想尋找論文的話，GitHub 庫 Papers We Love 是一個推薦。
去參與一些大項目
經驗比任何東西都寶貴。不是每個人都有機會去嘗試，但如果有時間，你可以試著去做一些大項目。你甚至不需要去完成它們。僅僅是嘗試寫一個編譯器之類的東西，這就能在開始幾周教你很多東西。
說實話，我很討厭那種我不知道如何解決複雜問題的感覺。這讓人很痛苦。在接近解決方案前，我必須做大量的研究和學習。有過這樣的痛苦經歷後，我總是可以得到提升，成為更優秀的程式設計師。
從學習一門新語言開始。這是幫你擺脫當前習慣和從新角度看問題的最有效方法。
對我來說，當我還是一個年輕的程式設計師時，我做的最好事情就是學習 Scheme 。這是一門非常簡單的語言，它會強迫你以函數式的方式完成所有事情，並真正了解代碼工作的基本原理。我在 Scheme 上花費數年時間，直到今天仍然受益。並且，我對代碼的看法發生根本性改變。
建議做的六件事
我推薦做幾件事，這些都我的程式設計師生涯產生重大影響。並且，他們中的許多事直到現在還以微妙的方式影響我，幫我對新想法進行分析。為了成為一名優秀的程式設計師，你無需做完全相同的事，你可以學習很多其他東西提高自己。
1. 學習 C 語言——如果你沒學過，學一些基本的就夠了。試著去想想，為什麼每個人都抱怨它，這件事非常有價值。
2. 寫一個編譯器——這可能讓你很不爽，可以看看 super tiny compiler 項目。
3. 學習宏——請參考 Scheme、Lisp 或 Clojure（腳本）。宏會真正改變你對代碼的看法。
4.SICP—— SICP 是一本舊書，我認為直到今天仍然很有價值（有些人或許不贊成這個觀點）。只要你有很少的編程知識，它就可以引導你一直實現 a meta-circular evaluator 和 compiler。另一本，我很喜歡並在編譯器方面做過深入研究的書是 Lisp In Small Pieces 。
5. 了解 Continuations： Continuations 是一種低級的控制流機制。Scheme 是唯一實現它的語言。雖然你永遠不會在生產環境中使用它們，但它們會改變你對控制流的看法。我寫過一篇試著解釋它們的博文。
6. 如果有可能的話，試著使用一種新語言：不管你做什麼，你真的應該探索其他語言。我推薦以下任何一個：Clojure、Rust、Elm、OCaml/Reason、Go 或 Scheme 都可以。它們都有自己的特點，可以驅使你學習一種新的思維方式。
關注我並轉發此篇文章，私信我「領取資料」，即可免費獲得InfoQ價值4999元迷你書！