为什么美国程序员工作比中国程序员工作轻松、加班少？ 第1页

美国程序员工作比中国程序员工作轻松、加班少总体来说是事实，但都归结到美国程序员效率更高，制度更好之类就过于片面了。我觉得主要原因在于别的一些地方，例如加班的边际效用，程序员的生活习惯。

背景：我在baidu（北京）和amazon（湾区）都干过，微软研究院（北京）和google研究院（湾区）也实习过，因为目前做云计算和开源，所以也接触过很多公司。整体来看，

1. 不觉得美国程序员比国内程序员水平高多少，特别是在年轻人身上。2000年后计算机专业红火，学生生源好，这些人是当前程序员的主干力量。而且中国教育在工程学科上更加扎实，适合培养程序员。
2. 美国有非常厉害的领导者，例如几家大公司创始人都很厉害。但加班文化更多是每个项目的实管人控制。我见过好的，也见过差的。虽然没有具体统计过比例，但没觉得中美差异明显。
3. 美国这边开会确实要多一些，但这个也是美国教育重视沟通相关（3，4岁的小孩就开始练习演讲了）。开会对于大组织有用，这样可以几百人在同一个思想层面往前冲，但用这个来衡量百来人的小公司就不见得适当了。
4. 美国公司创新度更高，一是社会认可，二是不创新难有机会生存，三是国内只盯着创新的公司看。但创新公司加班很普遍，例如Tesla老大都睡在厂房。

所以我觉得问题在于一些更本质的东西。这里是我的几点观察：

第一是边际效用。美国社会成熟度比较高，在湾区生活的同学也许过去10年都感觉不到特别大的变化，而中国则翻天幅度，特别是互联网领域。例如手机支付，美国普及很难，因为信用卡已经很普及了，手机支付带来的好处不显得很大。但中国的基础设施没跟上，所以手机支付在便利性上提升特别大，同样的技术，大家会不惜余力的去推广。

经济学上这个叫做边际效用。同样的技术，中国的边际效用比较高，所以大家可以全力推广。美国因为起点高，所以更加谨慎一些。

这个影响到了加班文化。通过加班可以完成更多工作。如果项目经理觉得这些工作带来丰厚回报，他们肯定会压着组员做。在中国很可能是这样，例如做出这个产品马上会有人用，升职加薪跟着就来。然而在美国，即使今天做出来，用户也是慢慢的过来，完全不需要急着那么几天。

第二是生活习惯。美国程序员年龄普遍偏大，因为计算机行业在2000年在美国就很红火（参考互联网泡沫），培养的大量的程序员，这些人现在很多都有小孩。在美国小孩都是自己带，双方父母不怎么帮忙。请人又特别贵，例如湾区工作日请人带娃一个月起码是2千美金起。而且学校课程松，所以放学后都要靠父母照顾。此外，很多人住的房子都带院子，请人打理费用贵，很多时候大家亲自动手。例如Robin在创立百度前曾醉心于在湾区种菜。

于是在加班边际效用不高的情况下，大家纷纷早点下班回家做家务。并冠冕堂皇的叫work-life balance。

我认识好几个未婚朋友，他们觉得每天那么早下班实在是太寂寞，毅然回国去了创业公司，并对996大家赞赏。记得Andrew Ng也表达过类似的观点。

但反过来说，早9晚5真的好？计算机技术日新月异，而且随着经历增长，需要提升各项领导能力。这些都需要足够多的时间去学习。我认识的厉害的人无一不是在下班后努力挤出时间工作，丝毫不比996工作时间少。与其现在羡慕别人轻松，不如埋头努力工作十年再来看。

===19年更新===

我对答案中对996淡淡的赞同表示很惭愧。反观我自己，在身体和家庭允许的一些时间里，可能每周会工作60、70小时。但如果每周坚持是不可能的。很是不赞同企业家大肆鼓吹必须996。

又看到一波人再扯什么企业文化，法律制度，科学管理，好像不扯这些不能体现出自己思考的深刻。好在我也工作快20年了，这些装*的东西也见过不少了。把自己在一篇回答下的评论搬过来吧，口语化的东西，没有什么深刻的道理，高大上的概念。只是觉得知乎一些人没工作几年，凭着自己短暂的几年认识，就下论断未免太片面，随性了。

=====

说句不好听的，那是因为当前美国行业状况，没有什么值得码农去拼命的了。我以前那个美国公司，2000年股票泡沫的时候，全公司的码农都拿睡袋睡在办公室。产品做出来就能IPO，IPO了就能发财，大家都明白股市这么火爆，多少年才碰到这么一次。隔壁公司的Tom已经买跑车了，你拼不拼？不拼就滚蛋，别挡着别人的财路。

国内整体行业环境还是处于拼命工作，就能让自己收入档次上一个台阶的地步。所以大家拼命加班。要是像美国2000那次一样，拼命就能发财，加班会很狠。什么企业文化，什么技术水平，什么法律保障，都是扯淡。老美的清教徒文化，不仅仅不排斥努力工作，还把这个作为优良品质。但是老美是资本主义，一切向钱看，努力加班又挣不到更合理的回报，我这么拼命干嘛？至于技术水平这些，就更是搞笑了。美国这垃圾代码的低水平码农多的是，我没见他们就加班了，反倒是高水平的程序员更能接受加班。至于法律规定，难道现在工会的大妈2000年的时候都还年轻，更富有激情？

很大一部分原因是从业者平均年龄。美国的码农平均年龄远远高于中国。

中国的码农群体因为极速扩张，干活的人多数是刚毕业的二十多岁年轻人。而美国的码农群体比较稳定，很多40岁左右的人还在一线写码。甚至60多岁还在写码的也不少。

20多岁的人加加班也不会怎么样，尤其是被老板压榨习惯了的研究生，下班在家吃喝玩乐的时候还会有点虚度光阴的负罪感。但是40多岁的人有家庭有孩子，身体也不行了。即使想长期加班，大多数人也是做不到的。

实际上美国很多小公司也加班，尤其是startup。比如andrew ng的startup招人的时候要求愿意每周工作70个小时。还有马斯克的tesla和spacex都是著名的血汗工厂，996不是梦。

但是由于从业者平均年龄在那里，当公司员工越来越多的时候，员工平均年龄必然会越来越接近行业平均水平。而年纪大的员工真的加不动班，慢慢就大家都不加班了。

所以中国码农的未来还是乐观的，就靠诸位再熬十年，然后自己去争取了。当然还有一种可能是中国码农数量继续指数增长，十年后诸位媳妇熬成婆，继续带着年轻人加班。。。

嗯，被经理举报了：

现在我切换到表扬模式。

是的，他们效率更高。

但是，国内程序员不可能通过提高效率减少加班和压力。因为这事的决定权不在你而在公司。

之前“开发和产品经理因为识别手机外壳颜色而打架”的传闻之所以能引起广泛共鸣，就是因为这类事实在太普遍了，太多人感同身受。

因为中高层聪明。太聪明了。聪明绝顶、英明神武、别具慧眼、大巧若拙、福慧双修、绝圣弃智、兰芷蕙心、七行俱下、上智下愚、秀外慧中、足智多谋、聪明绝世、聪明睿智、聪明正直、精明能干、才清智高——人家喜欢听好话，咱得多说。尤其像这个水平的，起码值一千个关于聪明的形容词，对吧。

可惜俺才疏学浅，实在凑不够数。只能列出八百个——不信您数数，足斤足两，一个不少！

啊？别看评论区。那都是不识数的。数到八百太难了，也就您这么聪明的能数清。不信您点点，八百！少一个俺再赔你一千个！

怎么样？满意了吧？

满意了我们继续。

所以，当你花大力气设计了一个精简高效的架构，把一个很难的问题干净漂亮解决掉时，绝不会有人击节赞叹——恰恰相反，他们觉得你捣鼓了个把月才产出几百行代码，反而会犯嘀咕：这人是磨洋工呢，还是不会？

你面向搜索引擎编程，乱七八糟拷一大堆东西到代码里，用到用不到都留着，KPI表现反而会特别亮眼。

一天几千行代码当然亮眼。

一群外行，怎么会知道这几千行里面就两行有效呢。

类似的，你兢兢业业，一个bug都不让出，人家就把你忘了；反之，你大大咧咧，一个功能你能写出800个bug——经理看起来就很忙很努力，因为他得不停的和你交流；你也很忙很努力，不停跑经理那里讨论问题：全公司你最忙你经理最敬业，不奖励你俩还有天理吗？！

你看，你好我好大家好，身为聪明人，你为什么不多写点bug呢。

当然了，这是极端情况。大多数公司还是没这么极端的——他们的中高层还不是那种聪明绝顶、英明神武、别具慧眼、大巧若拙、福慧双修、绝圣弃智、兰芷蕙心、七行俱下、上智下愚、秀外慧中、足智多谋、聪明绝世、聪明睿智、聪明正直、精明能干、才清智高的。

即便如此，他们中的绝大多数——包括多数程序员——仍然不懂软件工程。

他们并不知道，或者说并没有想过，今天你写的每一行代码，都会是明天的新代码的地基。

即使你知道，也没办法让中高层明白。

如果你今天写的太过随意，明天就很难在这个基础上扩展它；如果你着急完成任务，今天不先把昨天的设计缺陷修改掉，而是想一个办法绕开……那么明天你就不得不绕着圈子躲开更多问题。

越往后，就越难改；越难改，就越容易出bug。

但是，如果你想改昨天的代码，你就得先解决前天的问题；想解决前天的问题，大前天乃至大半年前的设计缺陷你就得逐一解决掉。然后，这大半年里，你就完不成任何新提的需求。

反正至多做三两年我就要换工作了。随他去吧，完成眼前的工作要紧。

因此，为了急功近利的眼前效率，中国程序员的长远效率自然变得极低——越往后越低。

我曾经接过一个任务。

因为高层设计的严重问题，我们不得不在网络通信层去更新用户登录状态（稍微懂点的都知道这需求有多奇葩：打个比方的话，这就好像让发动机制造商在活塞上做一个阀门以便随时泄压一样怪异。原因是我们的整车商忘了装启动机也没有离合器，所以需要减轻发动机阻力方便人家把车推起来）。

项目经理不懂。他觉得一条SQL语句也就是0.0x秒的事，我们的流程耽误1秒问题应该不大，所以就答应了。

我说每个用户都可能卡这么0.0x秒，人多了咱这模块吞吐量就没法看了。这个咱不能接。真要接也行，得改成多线程架构，得多安排时间。

经理说没事，直接加就行。做出事了他们负责就是（言外之意，一旦接了这个，将来我们自己的锅也有办法拉他们一起来背）。

既然都这么说了，我就动手做。

做完，内部测试没有任何问题；但一上线，整个系统死了。

原因是，那个库负荷特别大，一条数据库更新语句能卡几秒甚至几十秒。将来人多了还会更卡。

经理说，算了，你改多线程吧。

我思考了三天，决定不动我们这边的架构；而是设计个thread_call接口。任何传给thread_call的函数都会在另外的线程里执行——为了避免读写到调用函数的局部变量、然后在线程执行时调用函数已退出，thread_call内部会自动申请内存，把转交给工作函数的字符串等通过指针引用的参数统统复制过去；当线程执行结束，函数返回值也会保存在某地等待查询（超时或查询后自动删除），同时释放用到的资源。

为了实现这个，需要一个全局单例类负责管理线程、及时清理用到的资源；同时最好有一个线程池和一个内存池，免得频繁申请/释放。不然长时间运行下去，把内存弄的千疮百孔，程序就更容易出问题了。

内存池我已经写过一个泛型版本，直接拿来用就行。剩下的线程池、资源自动申请/释放（基于RAII和泛型，不支持原始指针因为无法确认空间大小、也无法确保复制成功，玩过泛型的都懂），加起来一百来行代码解决。最终代码量300多点，其中一大半是注释。

这个东西轻松的一次编译通过；然后挺过了各种测试，没发现任何问题。

这东西差不多相当于给C做了个简易协程框架（当时协程概念还没流行起来，不然我就把yield也实现进去了），今后遇到任何类似的“需要并行工作、但又不涉及数据竞争”的需求，直接写个处理函数然后丢给thread_call执行就好。

你看，如果程序都照这样写，是不是就会越写越快？

因为你昨天写的东西，今天可以拿来就用。写的越多，积累越多，实现新功能时需要重新实现的东西就越少，效率自然越高。

但是这个东西让项目经理作了难。

这是因为，如果算KPI的话，等于我花一周写了300行代码；然后又测了一周……两周300行代码的产出，这实在太少了。

反观别人，一个用户注册，人家一个字段一个字段一个字节一个字节的用代码检查、复制，轻轻松松搞出来500行。很水的几个功能轻松灌水上万行代码，然后部门KPI也有了，个人重要性也体现了——而且修不完的bug：你看，离了我们这个部门，公司真不能过啊！

可我傻乎乎的300行代码搞出这么复杂个东西，竟然还测不出bug……项目经理是知道这里面功能多，但上面觉得你忽悠他。300行代码你还能吹出花来不成？

而且，既然没有bug，以后人家还需要你这个部门吗？问题都解决了，我们这些人……还有继续雇佣的必要吗？

总之，他希望以后再写程序，尽量写长一些……而且，为什么要复用呢？其实每一个类似的需求，都是可以给他整个几万行代码出来的嘛。

没错。人家的预期是：这是个挺复杂挺难的任务，你应该加班加点忙上几个星期，提交几千上万行代码，到时部门KPI有了个人业绩也好看——将来每个类似任务都应照此办理。

而我呢，轻轻松松300行代码，杜绝了类似任务的出现——什么都不用管，加一行thread_call，全都妥妥贴贴了。

一个任务对应一行，这KPI还能看吗？

你看，面向目标的不同，面向KPI编码就必然使得实现臃肿、问题频发、每天996过劳死……但做起来其实轻松愉快，因为你完全可以磨上仨月洋工，然后吹嘘“多线程有多难”；然后还能让高层不断找你、解决诸如野指针、数据脏读脏写、死锁、内存碎片导致长时间运行后大块内存分配失败等等等等疑难问题——既让你显得重要，又能轻轻松松“骗”来大量的KPI，最后还不需要去学鬼画符一样、难的不要不要的泛型技术……

而面向问题编码呢，借助泛型，自动识别、复制函数参数（它们可能来自调用者的栈，随时可能失效），再加上用池来加速资源回收/分配效率、提前杜绝内存碎片问题——这完全是个简单轻松解决的小模块。而且只需解决一次，我们自己的“类协程库”都出来了，以后写程序会越来越快、越来越好：你甭管我怎么做完的、耗了多少时间，功能点我给你实现了、上线后bug free，是不是对双方都有利？

但是，后者在这个公司行不通。

代码量少没KPI你气不气？

bug写的少没人找你显得你不重要，倒霉不倒霉？

将来项目失败抓人背锅时，别人说我天天加班996007态度端正；而你呢，955一分钟班不加，这态度是不是很能说明问题？

从上到下都不懂你能怎么的？

别说这家公司的管理者了，他们的技术人员自己都不懂。我两个关系比较好的同事，还真以为我们是公司里干活最少、最不重要的几个呢。

因为别人忙忙碌碌总有干不完的活、修不完的bug，高层中层领导天天围着转，求爷爷告奶奶但任务就是做不完，重要的不得了。而我们几个公司公认的技术专家呢，每天到时间就走；座位上冷冷清清，从无领导过问；经常上班时间闲极无聊于是借“学新技术”的名义逛论坛……

时间久了，他们自己都心虚：为啥别人总是有干不完的活、见不完的领导？为什么我们经常整周整周的没有任务、闲坐着发呆？人家是不是比我们干的多、任务难啊？不对啊，每次分配任务，分给我们的，都是别人接不了、不敢接的啊？

直到有一天，午饭后散步聊天打屁谈到这事，我才觉得不对，提议回去看看工作日志/提交记录之类东西。

那天我们大概照例聊到了下午三点吧——没错，因为事少，因为要都要不来工作，一个月至多也就忙一周，955都大块大块的空闲时间。别说加班了，平常上班我们都经常偷空出去散步。

悠哉游哉回到公司之后，我们就去翻看所有同事的提交记录和bug报告数据。这才惊讶的发现，我们比其他同事完成的功能点数量高出5~10倍、难度也普遍更高，bug率却近乎为0——别人一个功能点能有密密麻麻几十个bug，而且上线几年bug都抓不完；而在我们看来，这些都是压根就不应该发生的低级错误，而且我们提交的代码的确不包含这类错误。

所以，别人一年只做三四个功能点，每个功能点都要出十几、几十个bug；而我们呢，一年起码几十个功能点，加起来不过3~5个bug（我更是一年只有1个bug，而且bug原因还是需求没写清：某个字段让返回字符串，我按照C惯例后面加了个‘’；对方用的java，不能识别这个）。

问题是，“我们接的任务最多最难”，这事我们项目经理知道，中高层领导不知道。

中高层领导知道什么呢？他们只知道，这个任务总是在别人那里卡住；他们只知道，系统出了问题，该找的人肯定不是我们几个（从不出bug自然不需要找）——所以你猜，在他们心里，谁更重要？

于是我决定辞职。

这是我第一次进这种公司，也是最后一次。

因为这种公司完全是“逆淘汰”。水平越差越吊儿郎当越吃香，水平越高越兢兢业业越被边缘化。