这个问题，几乎是每个工程师的“灵魂拷问”。感觉自己一坐下来敲代码，就能创造一个世界；一被拉去开会，就感觉生命在流逝。这个感觉太正常了。
咱们可以从两个角度来看“高效”这件事。
第一，从“个人产出”的角度看，你绝对是写代码更高效。
写代码是一种创造性的、有即时反馈的工作。你写了一个功能，它就动起来了；你改了一个bug，程序就正常了。这种感觉就像一个工匠在打造一件作品，每一下敲击、每一次打磨，都让作品离完成更近一步。这种产出是可见的、可量化的，能带来巨大的成就感和心流体验。一个小时的代码时间，可能就意味着一个新页面的诞生。
而开会呢？一个小时的会，你可能大部分时间在听别人说，或者在进行一些看似“务虚”的讨论。会议本身不直接产生代码，不直接修复bug。从这个角度看，它当然是“低效”的。
第二，从“团队产出”和“避免浪费”的角度看，有效的会议可能比你一个人埋头写代码更“高效”。
我打个比方：我们要造一艘船。你是个顶级的木匠，给你木头你就能飞快地造出船身。
-
场景一： 你不跟任何人开会，拿到木头就开始干，凭着自己的想象和经验，吭哧吭哧一个月，造出了一个精美无比的船身。结果这时候设计师跑来跟你说，客户的需求改了，我们要的不是尖头船，是平头船。你怎么办？一个月白干了，所有东西都要推倒重来。
-
场景二： 动手之前，你花了半天时间，跟设计师、销售、还有负责做船帆的同事一起开了个会。大家把图纸对了一遍，确定了船的尺寸、形状、用途，以及每个人的分工。虽然这半天你一块木头都没碰，感觉“没产出”，但它保证了你接下来一个月的辛苦工作，全都是在正确的方向上。
这个“开会”的过程，就是为了对齐目标，同步信息，消除障碍。它的作用是确保团队里的每个人，都朝着同一个方向使劲，避免大家因为信息不通畅而做无用功，或者互相“打架”。
一个好的会议，能解决一个关键决策，能让一个项目少走几周的弯路。这种“效率”是指数级的，只不过它不像写代码那样能被立刻看到。
所以，你的感觉没错：就你个人而言，写代码的单位时间产出，远高于开会。 这是你作为工程师的核心价值所在。
但是，对于整个团队和项目而言，一个简短而高效的会议，所避免的未来成本和浪费，可能远远超过几个工程师几周的工作量。
创业公司尤其如此，资源有限，试错成本高，最怕的就是整个团队埋头狂奔，结果发现跑错了方向。
当然，现实中我们烦的不是开会本身，而是那些“无意义的、冗长的、没准备的、不知道为啥要开的”会。所以，关键不是要不要开会，而是怎么把会开好，让它真正起到“对图纸”的作用，而不是浪费大家的时间。