软件开发就是创造力，对吧？这是一门艺术，而不是一门科学。作为软件工程师，我们解决复杂的问题，而我们的解决方案往往并不明显。我们进行实验、创新、研究和调查。要做到这一切，我们 谈谈 。我们坐在会议室、Skype 电话会议或 Slack 频道中；我们讨论我们的解决方案；我们征求同事的意见；我们争论最好的想法。毫无疑问，会议是现代软件设计学科的关键组成部分……看到它真是 令人难过 。
迈克尔·曼 (Michael Mann) 的热火 (1995)
一个好的软件架构师不需要开会，也 从不 组织开会。
会议会让人失去动力、浪费时间、烧钱并降低质量。但稍后会详细介绍。现在，让我们讨论一个提议的替代方案。
假设我是一名架构师，需要在新项目中为关系数据库设计架构，我有一个由五名程序员组成的团队，我想帮助我进行此设计。这是一个非常合乎逻辑和适当的愿望，因为优秀的架构师总是在做出最终决定之前与可用的团队成员讨论所有可能的选择。所以我要开会？不！
一个好的建筑师
我请我们的一位程序员杰夫创建数据库模式的草稿，但实际上我并没有和他谈过这件事。我重视并尊重他的时间——没有必要用这种组织噪音来打扰他，所以我只是创建了一张票并将其分配给杰夫。当他有时间时，他会创建一个草稿并返回一个 pull request。在他更新分支之前，我对其进行了审查并发表了一些评论，最后我将其合并。
完美的;我们有一份草案。
在文件的最后，杰夫还列出了假设、风险和担忧。例如，这是我从他那里得到的（它是 markdown，一种非常方便的简单技术文档格式；我强烈推荐它）：
## tables
user (id int, name varchar, email varchar);
payment (id int, date datetime, amount int);
order (id int, details varchar, user_id int fk(user));
assumptions
- all payments will be in whole dollars, no cents.
- all users will have only one email.
- there will be no search feature required.
risks
- order details may not fit into varchar.
- foreign keys may not be supported in the dbms.
concerns
- would nosql be more suitable?
- what is the db server we'll use?
我不知道杰夫会花多少时间在这个文档上，但我只用了 10 分钟就创建了它。当然，对于一个非常简单的项目来说，这是一个非常简单的模式。但即使杰夫花了一个小时，那一小时的每一分钟对项目来说都是有价值的。我的意思是，我为杰夫的时间支付的每一美元都会以文本文件的形式退还给我。
现在我有一个草稿，我正在做下一步。我请莫妮卡看一下并提出修改建议。又过了一个小时，我收到了一个包含更改、更正、新假设、新风险和新问题的拉取请求。我不是在和莫妮卡说话——没必要那样。她拥有使用数据库模式所需的所有信息。她是一位优秀的工程师，我相信她有能力以书面形式表达自己的意见。
无需坐在同一个房间或站在白板前。莫妮卡很聪明，可以自己完成这项工作。她已经把杰夫表达的所有想法都摆在她面前了；她也没有必要和他说话。
一旦我合并了她的拉取请求（经过适当的审查和更正之后），我就有了我的
schema.md
文档的新版本。
此外，我有该文档的 git 历史记录，并且我有带评论的拉取请求的历史记录。这比会议记录甚至会议视频要好得多。任何后来加入该项目的人都能够理解我们是如何得出使用 postgresql 并在没有美分的情况下存储货币金额的结论的。这一切都在 git 历史和 github 票证中，永远与我们同在。
如果我需要更多意见怎么办？或者如果我仍然不确定架构是否足够好？没问题;我请其他人再次审查它并向我发送一个包含更改的拉取请求。在与其他程序员进行几次迭代后，我什至可以让杰夫再做一次！
此外，我可以将自己的顾虑添加到文档中，并在下一次迭代中让jeff 关注并解决它们。
我们越圈这个文件，它就变得越好。项目付出的每一分钟都变成了有形的产品：具有更改历史的 文档 ！
这就是专业建筑师收集意见并做出复杂决策的方式。现在让我们看看一个糟糕的建筑师会做什么。
一个糟糕的建筑师
我先召集一个会议。不，等等；我在谷歌日历中安排它。不，等等，等等。首先，我制定一个议程：
## tables
user (id int, name varchar, email varchar);
payment (id int, date datetime, amount int);
order (id int, details varchar, user_id int fk(user));
assumptions
- all payments will be in whole dollars, no cents.
- all users will have only one email.
- there will be no search feature required.
risks
- order details may not fit into varchar.
- foreign keys may not be supported in the dbms.
concerns
- would nosql be more suitable?
- what is the db server we'll use?
我相信你知道我在说什么，你已经从你的“建筑师”那里看到了这些议程。不管怎样，我的第一步已经完成了。我已经安排了一个半小时的会议，所有程序员都将出席。我们会玩得开心，喝咖啡。我们将讨论问题，听取所有意见，并找到最佳解决方案。我们将在
schema.md
中记录它并返回到我们的任务。
我们将不再传播那些 枯燥乏味 的 git 文档，而是进行真正的人际交流和愉快的咖啡休息时间，我们将分享我们对 bing bang 理论最后一集的看法。这不正是我们都喜欢办公室工作的原因吗？
我不这么认为。
我认为会议会让人失去动力、浪费时间、烧钱并降低质量。那些组织他们的人要么不知道他们在做什么，要么在默默地 抢劫 他们为之工作的公司。
30 年前我们需要开会，那时我们没有笔记本电脑和 github。但即便如此，我们还是有笔和纸。
我说的是旨在收集或分发信息、讨论或提出建议或在 技术 领域寻找解决方案的会议。开会的唯一 有效目的 是阅读与你打交道的人的 肢体语言 。政客、商人、扑克玩家、心理医生、医生等——他们需要会面，因为他们必须了解我们的身体，而不仅仅是我们的想法。
在设计数据库模式时，我们真的关心莫妮卡的身体吗？嗯，这取决于，对不对？但让我们认真一点；我们没有为此付费。
会议使人失去动力
对有创造力的人来说，最好的动力就是看到他或她的创造力的结果。如果我没记错的话，享受创造的过程而没有任何结果是精神疾病的明显标志。例如，像软件工程师这样健康且富有创造力的人希望看到他或她的努力如何转化为有价值的东西，最好是有形的东西。
会议几乎从不产生任何有形的东西，也很少产生有价值的东西。有时我们有会议的“会议记录”，但它们只是简短的纸片，对我们所讨论的内容进行了简要总结。对于有创造力的人来说，这不是真正的“产品”。
因此，它们使我失去动力，因为我根本看不出我生命中的两个小时变成了什么。我们并没有真正 创造 任何东西，我们只是讨论。注意这里；我说的是会议，而不是协作工作，例如结对编程。
你可能会说有些会议实际上产生了很好的想法，这是非常有形的结果。你可能会说，只有在直接的、面对面的环境中，这些想法才能诞生。你也可以说，许多聪明的技术决定正是由于朋友们在同一个房间里在同一个方向、同一个时间思考的神奇协同作用而发明的。这个论点是有道理的，但我稍后会解决这个问题。
会议浪费时间
我认为这很明显。在会议的前几分钟，你很专心；然后你开始检查你的推特提要和涂鸦。每个人都在做同样的事情——不是因为我们懒惰，而是因为我们 不需要 在会议上全神贯注。
当莫妮卡处理文档、提出意见和建议时，她全神贯注于结果——主要是因为没有其他人可以帮助她。她必须交付那个拉取请求，我在等她。她的注意力和在会议上一样高，当有人直接问她一个问题时，她必须提供详细的答案。
当其他人都在做其他事情时，她的时间被优化以获得合适的结果。
另一方面，在会议上，我们充其量只能集中注意力。会议越长，我们就越慢。此外，那里的人越多，我们就越不关心，我们对 Facebook 更新就越感兴趣。如果您已经在软件开发行业工作了至少几个月，我认为这对您来说并不奇怪。
开会烧钱
这与之前的结论非常吻合。会议是项目中任何类型活动中最大的预算消耗者之一，仅仅是因为他们付钱给坐在那个房间或那个 Skype 会议上的 每个人 ，而他们产生的结果几乎等于一个人可以提供的结果。或更少。
尽管这听起来很极端，但我不得不说，我认为开会是 抢夺 项目的合法方式。大多数会议组织者（架构师、首席技术官、首席执行官、程序员等）都没有意识到这一点。他们相信他们说的越多，他们的工程师就越好。他们的老板错误地欣赏了下属的这种活动。
这是抢劫！
我告诉过你创建数据库模式的草稿。现在你来找我并要求会面是因为某些“方面”不明确？您在任何地方学习过软件工程吗？你知道如何处理技术文档吗？您是否能够以其他人都能理解和回应您的方式写作，即使是书面形式？不？现在你想让这个项目不仅支付你的数据库模式草稿费用，还支付我与你交谈的费用以及其他几个人坐在我们旁边给他们的朋友发短信的费用？你基本上想抢劫这个项目的所有者。不多也不少。
会议降低质量
当它受到控制时，质量会上升。当有人每天告诉我我的代码有问题需要改进时，我的质量就会提高。当没人关心我做什么或我的成绩有多好时，无论我多么有上进心，我的素质都会下降。
会议促进集体成就，阻碍个人成就。在会议结束时，通常不清楚谁提出了一个好主意，谁做出了最大的努力。换句话说，在会议结束时，我不知道自己有多好。我还是和一个月前一样还是我是更好的工程师？
他们笑得更开心了，问我“你觉得怎么样？”比去年夏天更频繁；那一定意味着什么，对吧？我相信你明白这不是一个认真的工程师所期望的那种反馈。
认真的软件开发人员希望产生有形的结果并获得有形的反馈，例如金钱或代码审查。我想知道我的数据库模式草稿中出了什么问题以及我错过了什么。我希望将其记录在某处。这就是让我变得更好的原因，这就是我学习和成长的方式。
那啊哈！片刻？
现在，真正的创造力或众所周知的“啊哈！”又如何呢？片刻？有时需要“大声思考”才能发明一些东西，对吧？我们都知道，当我们研究和开发新事物时，面对面的互动是多么重要。如果没有会议，我们会在哪里？我们不能简单地使用文档；我们需要互相交谈，以便表达我们的想法。这不是很明显吗？
对此我只有一个论据。爱因斯坦是在与同事会面时发明了他的理论吗？我不这么认为。他正在解决一个比数据库模式设计大得多的问题。
让我总结一下。会议是一项几乎不需要任何技能的活动，而用文本和图表记录想法则是一项更难完成的工作。因此，请训练和约束自己处理文档，让初级人员享受他们的会议。
