The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
软件开发完全是关于创造力的，对吧？它是一门艺术，而不是科学。作为软件工程师，我们解决复杂的问题，而且通常我们的解决方案绝对不是显而易见的。我们进行实验、创新、研究和调查。为了做到这一切，我们进行交流。我们一起坐在会议室里，通过Skype进行电话会议，或者在Slack频道里；我们讨论我们的解决方案；我们请同事们发表意见；我们对最好的想法进行争论。毫无疑问，会议是现代软件设计学科的关键组成部分……看到这一点真的很可悲。
一个优秀的软件架构师和优秀的项目经理不需要会议，也从不组织会议。
会议会让人失去动力，浪费时间，花钱，降低质量。但是这些我们以后再详细讨论。现在，让我们讨论一个提议的替代方案。
假设我是一位需要在新项目中设计关系数据库架构的架构师，我有一个由五名程序员组成的团队，我希望他们能帮助我完成这个设计。这是一个非常合理和适当的愿望，因为一个好的架构师总是在做出最终决策之前与团队成员讨论所有可能的选择。所以我要召开一个会议吗？不！
A Good Architect
我请我们的程序员之一 Jeff 来创建一个数据库模式的草稿，但实际上我并没有和他讨论过。我重视并尊重他的时间——没有必要打扰他这种组织上的噪音，所以我只是创建了一个工单并分配给 Jeff。当他有时间时，他会创建一个草稿并返回一个拉取请求。我会在他更新分支之前对其进行审查并发表一些评论，最后我会将其合并。
好的，我们有一个草稿。
在文件的末尾，Jeff 还列出了假设、风险和关注事项。例如，这是我从他那里得到的（这是 Markdown，一种非常方便的格式，适用于简单的技术文档；我强烈推荐使用它）。
## Tables
用户（id INT，姓名 VARCHAR，电子邮件 VARCHAR）；支付（id INT，日期 DATETIME，金额 INT）；订单（id INT，详细信息 VARCHAR，用户_id INT FK（用户））。
## Assumptions
* 所有支付金额将为整数美元，不包含分。
* 所有用户只能有一个电子邮件。
* 不需要搜索功能。
## Risks
* 订单详情可能不适合存储在VARCHAR中。
* 在DBMS中可能不支持外键。
## Concerns
* NoSQL是否更合适？
* What is the DB server we'll use?
我不知道Jeff在这份文件上花了多少时间，但我只用了10分钟就创建了它。当然，这是一个非常简单的架构，用于一个非常简单的项目。但即使Jeff花了一个小时在上面，每一个小时的每一分钟都对项目很有价值。我的意思是，我支付给Jeff的每一美元都以文档的形式回报给我。
现在我有了一个草稿，正在进行下一步。我请Monica看一下并提出修改建议。又过了一个小时，我收到了一个包含修改、更正、新假设、新风险和新关切的拉取请求。我不需要与Monica交谈—没有必要。她拥有与数据库架构相关的所有所需信息。她是一个优秀的工程师，我相信她能够以书面形式表达自己的观点。
没有必要坐在同一个房间里或站在白板前。莫妮卡足够聪明，可以独自完成这项工作。她已经拥有杰夫所表达的所有想法，也不需要与他交谈。
一旦我合并她的拉取请求（经过适当的审查和更正），我就会得到我那份 schema.md 文档的新版本。
此外，我有这份文档的Git历史记录，还有一系列带有评论的拉取请求历史。这比会议记录或者会议视频要好得多。任何后来加入项目的人都能够理解我们是如何得出使用PostgreSQL并存储没有小数位的货币金额的结论的。所有这些信息都在Git历史记录和GitHub工单中，将永远与我们同在。
如果我需要更多的意见呢？或者我还不确定模式是否足够好呢？没问题；我会再请别人再次审查，并通过更改向我发送拉取请求。甚至经过几次与其他程序员的迭代后，我还可以再次请Jeff来做这件事！
此外，我可以在文件中添加自己的关注点，并在下一次迭代中要求Jeff注意并解决它们。
我们不断围绕这个文件进行讨论，它会变得越来越好。而且，每一分钟的项目付出都会转化为一个有着修改历史的实体产品：一个具备变更历史的文件！
这就是一位专业建筑师收集意见并做出复杂决策的方式。现在让我们看看一个不好的建筑师会做什么。
A Bad Architect
首先，我召开一次会议。不，等等；我在谷歌日历中安排会议时间。不，再等等。首先，我要制定一个议程：
1. Introduction: 10 min
2. Problem: 15 min
- We need a DB schema
- Let's choose a server
3. Opinions: 15 min
- Jeff and Monica have experience
- Others?
4. Coffee break: 10 min
5. Discussion: 30 min
- Let's not forget risks
- Ask Joe about PostgreSQL
6. Conclusions: 10 min
我相信你知道我在说什么，你也从你的“架构师”那里看到了这些议程。不管怎样，我的第一步已经完成了。我已经安排了一个一个半小时的会议，所有的程序员都会出席。我们会玩得开心，喝咖啡。我们将讨论问题，听取所有的意见，并找到最好的解决方案。我们会在那个 schema.md 文件中记录下来，然后回到我们的任务上。
不要传阅那些枯燥无味的Git文档，我们将进行真正的人际交流，边喝着美味的咖啡边讨论《生活大爆炸》的最新一集。这不正是我们对于办公室工作的喜爱之处吗？
I don’t think so.
我认为开会会让人失去动力，浪费时间，浪费金钱，并且降低质量。组织会议的人要么对自己在做什么一无所知，要么就是在默默地“抢劫”他们所工作的公司。
我们在30年前就需要开会了，那时我们没有笔记本电脑和GitHub。但即使在那时，我们也有纸和笔。
我正在谈论的是旨在收集或分发信息、讨论或提出建议、在技术领域寻找解决方案的会议。会议的唯一有效目的是读取你与之打交道的人的”肢体语言”。政治家、商人、扑克玩家、心理医生、医师等等，他们需要开会是因为他们必须读懂我们的身体，而不仅仅是我们的想法。
当我们设计数据库模式时，我们真的关心莫妮卡的体型吗？嗯，那要看情况吧？但让我们认真点；我们并不是为此而付费的。
Meetings Demotivate
对于一个有创造力的人来说，最好的动力是看到他或她创造力的成果。如果我没记错的话，享受创造过程但没有任何成果是明显的精神疾病的标志。一个健康和有创造力的人，比如软件工程师，希望看到他或她的努力如何变成一些有价值的并且最好是有形的东西。
会议几乎从不产生任何有形的成果，很少有有价值的东西。有时我们会有我们会议的“会议纪要”，但它们只是一张简短概述我们讨论内容的纸条。对于一个有创造力的人来说，并不是一个真正的“产品”。
因此，它们使我失去动力，因为我根本看不到我生命中的两个小时变成了什么。我们在那里并没有真正“创造”任何东西，我们只是“讨论”。请注意，我说的是会议，而不是像配对编程这样的协作工作。
你可能会说，一些会议实际上会产生很棒的想法，这些想法是非常具体的结果。你可能会说，只有在直接面对面的环境中，这些想法才能诞生。你可能还会说，许多明智的技术决策正是由于在同一时间、同一地点的朋友们思考而产生的神奇协同效应。这个观点是有道理的，但我会稍后处理这个问题。
Meetings Waste Time
我认为这很明显。在会议的前几分钟里，你是专心致志的；然后你开始查看 Twitter 动态并涂鸦。每个人都在做同样的事情——不是因为我们懒散，而是因为会议上没有对我们全神贯注的需求。
当Monica正在处理文档、发表评论和提出建议时，她完全专注于结果——主要是因为没有其他人可以帮助她。她必须提交那个拉取请求，而我正在等她。她的注意力就像在会议上那样高度集中，当有人问她一个直接的问题并且她必须提供详细的答案时。
她的时间被优化以达到一个合适的结果，而其他人则在做其他事情。
在会议上，我们最多也只是勉强集中注意力。会议时间越长，我们的注意力就越不集中。而且，参会人数越多，我们就越不在意，更加关注我们的Facebook更新。如果你至少在软件开发行业待了几个月，我想这对你来说并不奇怪。
Meetings Burn Money
这与先前的结论密切相关。会议是项目中任何类型活动中最大的预算消耗者之一，仅仅因为他们支付在那个房间里或那个Skype会议上坐着的“每个人”的报酬，而他们所产生的结果几乎与一个人的产出相当。或者更少。
尽管这听起来可能有些极端，但我必须说我认为开会是一种合法的方式来“抢劫”一个项目。大多数会议组织者（包括架构师、首席技术官、首席执行官、程序员等）并没有意识到这一点。他们误以为他们说得越多，就越是优秀的工程师。而他们的上司们也错误地欣赏他们下属这种活动。
It’s robbery!
我告诉过你创建一个数据库模式的草稿。现在你来找我，因为某些“方面”不清楚，要求开会？你在哪里学过软件工程吗？你知道如何处理技术文件吗？你能用一种大家都能理解和回应的方式写作吗？不行？现在你希望这个项目不仅支付给你数据库模式草稿的报酬，还要支付给我与你交谈以及其他几个人坐在我们旁边发短信给他们朋友的报酬？你基本上想要掠夺这个项目的所有者。没有多余的，也没有少的。
Meetings Degrade Quality
质量在受到控制时会提高。当有人每天告诉我我的代码有错误并需要改进时，我的质量会提升。当没有人在意我做什么或者我的结果有多好时，无论我多有自我激励，我的质量都会下降。
会议促进了团体的成就，discourage 了个人的成就。在会议结束时，往往不清楚到底是谁提出了一个好主意，谁付出了最大的努力。换句话说，在会议结束时，我不知道自己有多出色。我是不是和一个月前一样，还是成为了一个better的工程师？
他们比去年夏天更频繁地微笑并经常问我“你觉得怎么样？”这肯定有什么含义，对吧？我确信你明白这不是一个认真工程师所期望的反馈类型。
一位认真的软件开发者希望产出有形的成果并获得有形的反馈，比如金钱或代码审查。我想知道我的数据库模式草稿有什么问题以及我漏掉了什么。而且我希望这些问题能被记录下来。这是让我进步的原因，也是我学习和成长的方式。
What About the A-ha! Moment?
现在，真正的创造力或众所周知的“灵光一现”呢？有时候为了发明一些东西，有必要“大声思考”，对吧？我们都知道当我们研究和开发新事物时，面对面的互动是多么重要。如果没有会议，我们会在哪里？我们不能仅仅靠文件工作；我们需要相互交流来释放我们的想法。这不是显而易见的吗？
我只有一个论点。爱因斯坦是与他的同事在会议上发明他的理论吗？我认为不是这样的。而且他解决的问题比数据库模式设计要大得多。
Let me summarize. Meetings are an activity that requires almost no skill, while documenting ideas in text and diagrams is a way more difficult job to do. So train and discipline yourself to work with documents and let juniors enjoy their meetings.
Translated by ChatGPT gpt-3.5-turbo/30 on 2023-08-29 at 06:27
