按时上下班的程序员，做出来的东西没有“弹性” | DIVE 全球基础软件创新大会
开发效率跟每个开发者和开发团队息息相关，高效率意味着可以在更快的时间内更好的完成更多的内容。但在互联网行业繁荣发展的同时不少企业还在使用“拼工时”的做法，加班、996、内卷等问题也是持续困扰多数开发者，似乎提高效率是一个很困难的事情。
在鉴释科技联合创始人兼首席架构师刘新铭（英文名 Shin）看来，关于如何提升研发效率的问题，要讨论的其实就是态度和时间管理。11 月 17 日，Shin 现身 InfoQ 大咖说，妙语连珠，结合自己的职业经历，给出了很多关于提升开发效率、做好时间管理等方面的思考和建议。
此外，在明年 3 月 25 日，Shin 还会在 DIVE 全球基础软件大会上做关于编译器的硬核技术分享，感兴趣的朋友不要错过。
以下内容节选自当天的分享，InfoQ 做了不改变原意的编辑：
Shin：我入行是 1984 年。从 84 年开始的 10 年时间，我都在做编译器，从最底层的开发人员做到惠普的整个工具链（Tool Chain）的负责人，负责整个工具链，包括了编译器、debugger 和性能分析器等，给惠普服务器、安腾服务器做的工具链。之后，我去做了两年操作系统，主要还是管理的工作，负责惠普分布性存储的内核部分，也是最难的部分。我们的主要工作目标是性能调优，把所有性能方面存在的大大小小的问题修复好。接下来还搞了三年的物联网，我在英特尔实验室做首席科学家，（担任）物联网实验室主任，在北京跟北京市政府合作做了几个物联网端到端的解决方案。后来，我就去了国外，在美国一家华人公司待过两年，帮他们做数字化转型，因为在那之前，该公司的软件都是用 Java 写的，我们把它变成更适合在现代的云端架构上面运行，所以这也是为什么现在在鉴释有关云方面的技术由我负责。
Shin：我从入行到现在，平均一周工作时间不会少于 60 个小时，这算加班吗？以美国为例，这不算加班。所有的专业软件开发人员或者职业经理人，在他们的劳工法里是归类为“豁免”的情况，不需要打卡。所有的工作是根据给你的内容来定，你的任务就是把它完成，花多少时间是你个人的事情，与公司无关，不会有人强迫你一周必须工作多少个小时，而是自己去判断应该花多少时间完成工作内容。
所以在美国，对职业开发人员来说，不管软硬件开发，加班这个词是不存在的。这里可能有人会说，那你一周工作 60 个小时不是吃亏了吗。其实你工作有一半是为公司工作，一半是为自己工作，永远要注意个人与公司之间的平衡。
这里提到的为自己工作就是为自己职业生涯做投资。我做开发工作的时间多，又会去认真的思考的话，自然可以积累到越来越多的经验，个人的价值是会不断得到提高的。
从这个角度来说，我有一部分时间是在为自己工作，为自己加班，为自己投资。
Shin：国内的加班情况跟国外完全不同。我刚才提到了我是每周工作 60 个小时，一周六天，平均一天就是 10 个小时。但是国内的员工就因人而异，我碰到过年轻的开发人员对知识非常渴望，对工作投入的时间会非常多，也遇到过斤斤计较，到点“失踪”的。这里面有一个很有趣的规律，你会发现一些比较重要或者难解的问题，慢慢会往愿意花多余时间工作的人身上去挪移。这些人会在公司里慢慢变成不可或缺的人。
另外做软件的话与硬件不同，软的意思就是说很有弹性。时间到了就要上班下班的人，他做出来的东西通常没有弹性，这是很有趣的事情。
Shin：这纯粹是时间管理的问题。以我个人为例，我尽量把我自己每天开会的时间压缩到不足 3 小时，剩余 3.5 个小时做比较困难的需要动脑的事情，3.5 个小时做相对简单的事情。这样的话一天就被分成了三段。那些斤斤计较每天 8 小时的，减去 3 个小时的会议，一般解决难的问题花的时间比较多，再减去 3.5 个小时，就只剩下了 1.5 个小时去做比较简单的事情。
可是很不幸的，简单的事情一般是决定于你自己的设计够不够好。结果就是大多数人，一天除去开会处理邮件的时间，剩余几个小时都在做杂七杂八的乱事儿，没时间去思考。当你没有时间去想和解决新问题的时候，价值就不会得到提升。
然后主要难的事情还没做的时候就开始焦虑，加班是被压力压出来的，不是自我管理出来的。我即使是一天工作 10 个小时，我心态是很放松的，但压力压出来的焦虑加班，就很痛苦。
Shin：我先讲一下我每天怎么分配自己的时间，通常的话我是早上 10:00 开会，我会 8:30 左右到办公室开始梳理当天的工作内容，会议要讨论的要点，要解决的难点痛点，就是把最好的时间放在最困难的事情上。到下午的时候才开始写代码，修改、测试、调优等，这些是不太用大脑的。
Shin：我在带新员工的时候也会遇到这样的情况，他们反馈说你让我做很多计划是无用的，因为不断有新的东西进来打乱工作计划。还是回到那句话，如果你设计的时候想的不够远，做出来的东西就会出现很多问题。你主动管理自己的时间，管理自己做的事情，积极主动去做设计。对自己做的东西有充分全盘理解的时候，即使是突然遇到的问题，你会比较轻松的定位到问题解决问题。
还是回到一个工作方法和态度的问题，一个积极主动的人他被动处理问题的情况要少得多。越认真的人，要处理的问题越少，也是很有趣的事情。看你把加班当成投资还是负担，在你付出的时间上，你是主动积极的做了规划，了解全盘，还是只是被动的去接受任务。所有的开发效率就是从这个过来的。
Shin：这个在网上大为传播是 Facebook，他们一个小团队是 5 到 6 个人，有 PM、测试、开发，每天开“站会”。“站会”这个其实是有来源的，在 1988 年有个电影《Stand and Deliver》（中文名《为人师表》），讲述一个高中的老师在洛杉矶的郊区教一群墨西哥移民的子弟。这些人基本上已经放弃了自己的人生，他就跟自己的学生打气，要站起来把事情完成，Stand and Deliver，所以“站会”是这么来的。
“站会”最重要的工作是在协调所有人当天的优先级，比如说两个开发人员说我需要 PM 做哪些决策，测试人员说我需要开发给我这样的信息去做哪些测试。是人跟人之间协调沟通的机制，通常合理的“站会”不能超过 10 分钟，超过 10 分钟，这个“站会”就没效率。
通过“站会”，小团队里要定义好我当天要完成什么工作，注意是完成什么工作而不是要做什么工作，这是国内和国外最大的不同点。一个好的“站会”是我昨天的工作完成了没，如果没有完成原因是什么，我今天的目标是什么，我可能会有困难，我需要某某人帮助我解决这些困难。这个时候小组的 Leader 就会知道基于这个互动沟通的过程去协调工作内容。
Shin：这个确实跟团队的大小有关系，Facebook 的标准配备是不能超过 6 个人，80 90 年代我们一个团队不超过 3 个人。国内的公司的话不缺人，一个项目就是会投入很多人员进去，每天都要开很久的会，没时间去做真正开发的事情，这不是很好的现象。
Shin：这个要看团队成员的素质。国内是最好的人在大公司，美国是好的人去新创公司，因为去大公司就是一个萝卜一个坑，你能碰到的东西是很有限的。在这种环境下，他那个小团队的人是很“饥饿”的，他们对知识的追求，对工作完美的追求是没上限的，这样的团队大了反而碍事。《Mythical Man Month》这一本书中也提到了，人数的增加不能增加你的产出量，到某一个临界值反而会降低你的产出量，因为你要花更多的时间去做沟通。当然小团队也有问题，如果成员素质差太多，沟通的成本也会上来。沟通的成本是由团队的素质、成员的数量、项目切割的碎片化程度三个因素决定的，效率也就因此而来。
Shin：我举一个例子，我们从去年的 9 月开始，把我们的软件从一个 Server 上搬到了云上，我们当时选的是亚马逊的云，因为他们云原生的架构比较完整。上云之后，我不需要再搞很多东西，之前在 Server 上的中间件等都可以丢掉。所以云原生带最大的价值，你原来必须要维护的中间件，都可以交给他们去做，我个人觉得效能提升是巨大的。最大是因为中间件大家都是开源的。
Shin：聪明的人是工具为他所用。我个人的习惯是自己造工具，根据自己的需要造工具，不管做什么事情，用什么工具，都是完成工作的目标，假设工具不能为我所用，我不会在上面浪费一分一秒。我对用什么工具没有意见，重要是顺利的完成工作。
Shin：我觉得主要是以下几个点。
第一，要改变自己的心态，你的工作是为自己投资，不只是还老板的债，让自己开心一点，为自己投资是开心的事情，还债是痛苦的事情。
第二，时间要管理好，每天要花足够的时间解决需要动脑的事情，这个东西其实是给自己设置了高标准，你不会去接完全是搬砖的活。这些是可以自己主动要求的，你有了第一个改变，才会有第二个改变。
第三，就是要评估自己工作的做的好不好。科学的做法就是大胆的假设，小心的求证。我个人觉得国内有个东西是不太好的。国内所有的团队开发人员，心理上对测试是排斥的，我个人不认为测试是单纯的测试，我把测试认为是一个求证的过程。
最后一个就是要看书，每周至少要花半个小时去看书，最重要的是你要跳出每天固定的思维，如果人一天一直是在一个圈里，长此以往，思维会固定住。也不建议看抖音，比较浪费时间，技术直播是可以看的。开车的是话可以听一些录音的书或者让自己放松的音频。每天多花点时间充实自己。
相关内容
微信扫码咨询专知VIP会员