看到這篇好幾天了，想想還是也來分享一點個人經驗
我自己在業界的資歷沒有很久，也不是本科出身。
從十幾年前玩 open source 專案，誤打誤撞一路寫 code 到現在，
後來去國立資工所洗了一下 XD 所以現在也號稱本科了
研究所畢業後進入稍有規模的新創，後來也待了大公司。
一路上體制外、體制內、開源專案、小公司、大公司都經歷一些之後，
在這幾個階段，學到的技能大多都不一樣，體驗也差很多。
先講結論，大公司小公司各有優缺，沒有絕對高下，會發展的是不一樣的技能，
如果對軟體開發很有愛，值得都去體驗看看，不要先入為主認為哪個一定比較強。
大公司的優點在於制度完善、而且很多事情都需要考慮世界級的規模，可以開眼界。
軟體工程的 best practice 和 code quality 也紮實很多，又有非常完善的 infra
的確是學習基本功的好地方，但缺點是每個人，甚至每個團隊會分到的，
常常是比較小規模的模組。大多東西都有人打理得非常好了，照著文件用多半沒問題，
比較少會自己動手去弄底層，而且十幾年疊床架屋的系統架構，真給你 code 也不是
打開就可以隨便改的，更不要說要動個小模組都要層層審查，到處 get approval。
如果遇到跨國跨時區做開發，做每件小事基本上就是以天為單位在計算，因為你發到
國外的東西，最快要隔天才有人審查。組織太大，有時候甚至不一定知道找誰。
除非你真的非常優秀，又在重要的位置上，否則要做到很大範圍的 impact 比較難。
以前曾跟某大公司資深人員聊，對技術細節很多都答不出來，因為一塊是A團隊做的，
另外一塊是B團隊做的，他做的事情就只是整合，很多細節也不用自己處理。
所以其實也不是大公司出來，就一定樣樣都會比較強。
相形之下，在小公司的步調非常快，畢竟明天的客戶還不知道在哪，
資源和時間總是不夠，計畫隨時都在改變，比起貫徹 best practice，更需要的是
高度彈性、抗壓性、跟快速適應變化的能力。很多事情並沒有專門的團隊負責，
如果你想要弄，基本上就是要自己動手。很多時候甚至還要兼部份 PM 的功能，
infra 有些也要自己來，所以在這樣的環境訓練下，技能樹容易比較寬廣。
又因為組織很扁平，很容易有機會帶領專案，也是訓練 leadership 的好地方。
但缺點就是很多事情都求快，所以容易做不深。不過因為組織扁平，所以要推動變革
相對也容易，獲得上層支持的話，要推動各種革新非常迅速，也不是真的都這麼淺碟。
公司在不同成長階段，需要不同類型的人才，所以重點不是大公司和小公司哪個
訓練出來比較好，這是多樣性光譜的兩端，一家公司兩類的人才都應該要有。
公司在存亡之際，客戶要求明天就要看到解決方案，而你來自大公司的的 RD 卻堅持
沒有 best practice 他不開工，code quality 太差不應該 deploy，而架設 infra 和
QA 不是他的職責，這樣新創公司是開不起來的。這種時候需要快速敢衝的人才。
但一旦商業上站穩腳步，就是該補上缺乏的制度和 best pratice 的時候，
這種時候，小公司的彈性和效率，搭配來自大公司的經驗磨合後，就會很有幫助。
但這時候 code base 會處在很可怕的狀況，有本事把技術債清掉，在 zero downtime
的狀況下導入更好的工程和系統架構，這種可不是普通的本事。習慣在良好 code base
下工作的工程師，未必有能力處理這樣的爛攤子，有時反而是新創野外求生出來的人，
對這樣的狀況適應得不錯。
落落長打了很多，我只是想要說不同的訓練，有不同的價值，應該兩者並用互補，
而不是爭大公司或小公司哪個技術好。
工程師總是在系統 constraints 下面做 optimization，而小公司就是 constraints
特別多，能在那樣的環境作到一定程度的表現，其實不會比在大公司不需要技術。
兩者都值得去體驗看看，都是不一樣的學習，其實都很好。