每位開發者都該看：如何在四十歲後還能繼續從事軟件開發？
這是一個 42 歲的開發者所寫經驗分享文章．並且列出一些他 18 年多身為軟件開發者的經驗談．許多部分看完後都會希望自己當時就能夠了解，所以很推薦不論是新手或是老手都要好好閱讀這一篇文章。
故事很長，一切從 1997 年開始講起．那是一個令人懷念的年代（FF7 發售，微軟入股蘋果，鐵達尼號電影上映），那是作者第一年身為軟件開發者的年份。當時他的第一份工作是從事 ASP 並且在微軟的平臺上面使用 EditPlus。十八年過去，作者一共做過六份工作，其中被炒魷魚兩次，出過兩本書，從事過不少演講。他整理了他的一些心得，希望年輕的開發者（或是有誌將軟件開發作為終生誌業的人）一些建議，條列如下:
1. Forget The Hype （忘記各種程序語言與架構的炒作與熱潮）
不少的新的語言與技術來來去去，作者不是要你別去學習新事物，而是不要因為有太多的新事物而恐慌或是自我放棄。持續鑽研你目前在學習的，並且可以每年挑一些你有興趣的項目深入了解。
[反觀我自己]：各種後端與前端語言來來去去，我把時間花在學習 Python（會持續）， Ruby，Scala（會持續）與 Golang（會持續）。透過使用 Golang 可以有更多的時間去了解系統架構與直接面對問題，讓寫代碼變得更有趣。
2. Choose Your Galaxy Wisely（慎選你的星系）
為了維持原文的意思，我還是使用星系這個字。這邊指的是你學習跟從事的技術要慎選，舉例而言，微軟星系（泛指: .Net、C# ….）或是 Apple 星系（Objective C++、Swift …）。慎選你喜歡的星系，因為那會影響你未來的發展。
[反觀我自己]：過去十年主要針對微軟星系，目前主要就是後端的 Ubuntu 星系 ，各種後端程序語言都是我目前主要的重點，當然還有 Docker 相關技術。
3. Learn About Software History（了解各種軟件的歷史）
作者認為如果你喜歡一種程序語言、一種架構，你就需要好好的了解它的由來與故事。
[反觀我自己]：比如說我喜歡 Golang ，我就應該要了解以下的一些問題：
Golang 是誰發明的？
Ans：由 Google 內部的三位大神 Robert Griesemer，Ken Thompson（C 語言的共同發明者）與 Rob Pike（UTF-8 的共同發明者），在 2007 年於 Google 內部共同起草發明。
他主要解決什麽問題？為何以前做不到？
Ans：根據第一份 Golang Talk
原因為：
Go fast！
Make programming fun again.
世界在變，但是系統語言卻已經十年沒變。
系統語言往往編譯過久。
為何以前做不到：（在舊的程序語言上做不到）
新增函式庫不是一個正確的方向。
需要從新思考整個架構來開發新的程序語言。
目前這個技術的最新狀況如何？
Ans：Golang 目前是 1.6.2 (2016/05/03) ，並且支援 HTTP2 並且可以透過 gomobile 在手機上也可以使用相關套件。
4. Keep on Learning （持續學習！）
不論你喜歡哪些新的技術或是新的程序語言，你都應該持續的學習，裡面並且建議：
每年學習一個新的程序語言。
每年讀六本書。（作者推薦 Peopleware、The Psychology of Software Programming、Facts and Fallacies of Software Engineering、Agile!: The Good, the Hype and the Ugly、Rework 跟 Geekonomics，都是好書。）
[反觀我自己]：
程序語言部分： 2014 (Ruby， Scala) 2015 (Go, Swift) 2016 還沒有決定．
讀書部分：每年讀沒有超過六本書，但是讀過不少論文並且有上過一些 MOOCs。
5. Teach（指導其他人）
這邊指的不是一定要開堂授課，你可以寫一篇部落格來講解你學習的新事物，因為教導是最好的學習方式。
[反觀我自己]：還好部落格從來沒停過，個人也認為寫部落格的過程可以讓我不斷地檢視我了解的部分，並且弄懂所有的細節（希望！），不過還是希望能夠多多指導其他人（比如說 meetup 或是 talk）。
6. Workplaces Suck（工作場所糟糕透了）
不要去期望軟件公司會給你任何職涯的規劃，相反的不少公司會將你認為是另外一種的勞工，只會將你放在你擅長的位子，所以也有軟件公司變成血汗工廠的相關文章。作者同時也認為開放性座位對於需要高度腦力工作的軟件工作者是一種最不好的設計（使用 “cancer” 這個詞)。而對於工作上的指派，作者也建議大家應該要好好了解每個任務的內容．有任何疑問應該要提出來討論，對於不了解的事物盲從是最不好的，應該不惜抗拒權威或是離職才是正確的選擇，不要讓這樣的工作風氣扼殺了你的熱情。
[反觀我自己]：我一向對於任何”不合理”的任務指派都會有意見，甚至不斷地提出抗議。（當然結果可能都不好！）但是如果因為這樣就不提出，那麽我們還剩下什麽呢？
7. Know Your Worth（了解自我的市場價值）
這篇是要大家充分的了解自己的市場行情（也就是薪水），根據這篇文章通常一個軟件工程師應該要能創造出他自己薪水等級的十倍價值。事實上可能遠遠不止如此，所以作者建議我們要勇敢地去爭取更多的薪水，甚至你可以公開你的薪水等級，讓更多人知道你是否被低估（或是高估）任何（自認為）有你相同能力的人，都應該拿到一樣的待遇。
[反觀我自己]：這件事情還真是難做到，在一間公司待久之後，最容易降低的就是薪水提升的幅度。這件事情還得努力學習，讓自己的市場價值更高．同時我們也要不斷檢視，我們自己能不能創造出自己薪水的十倍價值。
8. Send The Elevator Down （虛心地接受任何意見）
這邊我的解讀可能跟作者原先的不同。他有提到膚色與種族的優勢，但是我想到的卻是你的職位，你可能會聽到許多來自於部下或是後輩的建議（或是批評）。不要快速地想要反駁或是抵制，充分的了解過後，或許可以坦誠自己的見解或許是有盲點的，必要時甚至可以道歉並且快速修正。如同許多書上有提到的：「你雇用一個員工，一定是要比你還強的，這樣你才能將事情交給他辦，你自己做更需要更大視野的任務。」
[反觀我自己]：參加社群後，最容易有這種感覺：太多令人欽佩的後輩了，每個人都有著淵博而清楚的知識。我們不需要否認，更不需要去挑惕或是批評，我們要謙虛的接受並且吸收，成為我們自己的養分。
9. LLVM（一個自由軟件專案，是一種編譯器的基礎建設，以 C++ 寫成）
作者認為 LLVM 會是下一個重要的資訊業的星系（Galaxy） ，目前已經有許多的程序語言支援 LLVM 了。所以作者建議我們可以花一些時間去了解，或許去學習相關的程序語言。
[反觀我自己]：雖然 Python 與 Swift 都有學習，但是還不是我最上手的程序語言之一。這一個部分我會好好謹記於心，好好學習。
10. Follow Your Gut（相信你的直覺）
作者在 2000 年就覺得 .NET 會引領接下來的幾年，在 2007 年 iPhone 的發表會就了解他的相關技術會是緊接著幾年的發展趨勢。
當然，這是作者的直覺。但是，你也應該充分地相信你的直覺，並且努力的去追求與學習。
[反觀我自己]：我在 2014 年開始學習許多不同的程序語言， Python, Ruby， Objective C, Java, Swift, Scala 與 Rust。最後學習到 Golang，我直覺認為 Golang 會是 Server-side （或是說 Service-side）最重要的程序語言之一，所以我會努力學習。
11. APIs Are King（API 是王道）
這邊很推崇好的 API 設計是很重要的，不僅僅影響 server 與 client 的溝通，更會影響到好的軟件品質。也提出 chunky is better than chatty （簡單的說：就是不要將 API 拆的太精簡，使得 API call 需要往來相當的多次。）
同時作者也建議不要太依賴 REST ，不仿看看 socket.io, ZeroMQ, RabbitMQ, 或是 Erlang。並且也應該開始架設自己的機器人。
[反觀我自己]：沒有想過，原來 chunky 的設計準則在某些狀況下竟然比 chatty 更好，這得好好學習。我有架設自己的機器人來幫助我處理一些日常伺服器維護的瑣碎事項。
12. Fight Complexity（將復雜的事情簡單化）
永遠要秉持著 KISS 原則（“Keep it short and simple”）來處理任何事情． 面對困難或是負責的事情，有著不少工具可以幫助你將設計簡單化。
[反觀我自己]：我一直認為能夠越有能力的人，越能夠將復雜的事情簡單的講解，或是寫成一段簡單的程式碼來實現，這個能力是我們都要不斷學習的。
Conclusion（結論）
「年齡永遠不會是一個問題，只要你的心不斷催促你持續寫代碼，持續制造新的東西，你永遠都會是年輕的。」
這是作者給我們的結論，他也希望我們能夠保持一顆年輕的心，不斷學習。
在這裏也給大家推薦一個架構學習交流群：650385180，裏面會分享一些資深架構師錄制的視頻錄像：有Spring，MyBatis，Netty源碼分析，高並發、高性能、分布式、微服務架構的原理，JVM性能優化、並發編程這些成為架構師必備的知識體系。還能領取免費的學習資源，以下的課程體系圖也是在群裏獲取。
溫馨提示
如果你喜歡本文，請分享到朋友圈，想要獲得更多信息，請關註我。
有什麽想法可以評論留言。
每位開發者都該看：如何在四十歲後還能繼續從事軟件開發？