看到这篇好几天了，想想还是也来分享一点个人经验
我自己在业界的资历没有很久，也不是本科出身。
从十几年前玩 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
特别多，能在那样的环境作到一定程度的表现，其实不会比在大公司不需要技术。
两者都值得去体验看看，都是不一样的学习，其实都很好。