Meetings Are Legalized Robbery

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频道里;我们讨论解决方案;我们征求同事的意见;我们就最好的想法进行争论。毫无疑问,会议是现代软件设计学科的关键组成部分……而看到这一点真是非常“可悲”。

一个优秀的软件架构师和一个优秀的项目经理不需要会议,也从不组织会议。

会议使人失去动力,浪费时间,花费金钱,降低质量。但是稍后再说更多。现在,让我们讨论一个提出的替代方案。

假设我是一位需要为一个新项目设计关系数据库模式的架构师,我有一个由五名程序员组成的团队,我希望他们帮助我进行这个设计。这是一个非常合理和适当的愿望,因为一个好的架构师总是在做出最终决策之前与团队成员讨论所有可能的选择。那么,我要组织一次会议吗?不!

我要求我们的程序员之一Jeff创建一个数据库模式的草稿,但实际上我没有与他讨论过。我重视并尊重他的时间-没有必要打扰他处理这些组织上的琐事,所以我只是创建了一个工单并分配给了Jeff。当他有时间时,他会创建一个草稿并返回一个拉取请求。我会在他更新分支之前对其进行审查并提出一些评论,最后将其合并。

完美,我们有了一个草稿。

在文档的最后,Jeff还列出了假设、风险和关注点。例如,这是我从他那里收到的(这是Markdown格式,对于简单的技术文档非常方便;我强烈推荐使用它)。

我不知道Jeff在这份文件上花了多少时间,但是我只用了10分钟就创建好了。当然,这只是一个非常简单的计划,用于一个非常简单的项目。但是即使Jeff花了一个小时在上面,每一个小时的每一分钟对于项目都是有价值的。我的意思是,我付给Jeff的每一个小时的工资都以一份文字文件的形式回报给了我。

现在我有了一个草稿,正在进行下一步。我请Monica看一下,并提出修改建议。再一次,又是一个小时过去了,我收到了一份有修改、更正、新的假设、新的风险和新的关注点的拉取请求。我不需要和Monica交谈,没有必要。她已经有了所有需要处理数据库模式的信息。她是一位优秀的工程师,我相信她有能力以书面形式表达自己的意见。

没有必要坐在同一个房间里或站在白板前。Monica足够聪明,可以独立完成这项工作。她已经有了Jeff所表达的所有想法;她也不需要和他交谈。

在我合并她的拉取请求之后(经过适当的审查和更正),我得到了一份新版本的schema.md文件。

此外,我还有这个文件的Git历史记录,还有包含评论的拉取请求历史。这比会议记录甚至会议视频要好得多。任何后来加入项目的人都能够理解我们是如何得出使用PostgreSQL并且存储没有小数位的货币金额的结论的。这一切都记录在Git历史和GitHub的工单中,永远与我们同在。

如果我需要更多意见怎么办?或者如果我还不确定模式是否足够好?没问题,我可以请其他人再次审查并给我发送带有修改的拉取请求。我甚至可以在与其他程序员进行几次迭代后再次请Jeff做这件事!

此外,我可以在文件中添加自己的关注点,并在下一次迭代中要求Jeff注意并解决它们。

我们对这个文件进行的循环越多,它就越好。而且项目支付的每一分钟都变成了一个有形的产品:一个有变更历史的文件

这就是专业架构师收集意见和做出复杂决策的方式。现在让我们看看一个糟糕的架构师会做什么。

首先我召开一次会议。不,等等,我在Google日历中安排会议时间。不,等等,等等。首先,我创建一个议程:

我相信你知道我在说什么,你也见过你们的“架构师”制定的这些议程。不管怎样,我的第一步已经完成了。我安排了一个一个半小时的会议,所有程序员都将出席。我们会玩得开心,喝咖啡。我们将讨论问题,听取所有的意见,并找到最佳解决方案。我们将在那个schema.md文件中记录下来,并回到我们的任务上。

我们将不再传阅那些枯燥乏味的Git文档,而是进行真正的人际交流,并在愉快的咖啡时间里分享我们对《生活大爆炸》最新一集的看法。这不正是我们对办公室工作的喜欢之处吗?

我认为会议会让人失去动力,浪费时间,浪费金钱,降低质量。组织会议的人要么不知道自己在做什么,要么就是在默默地掠夺他们工作的公司。

30年前我们没有笔记本电脑和GitHub时,我们确实需要开会。但即使那时候,我们也有纸和笔。

我所说的会议是指为了收集或分发信息、讨论或提出建议、或在技术领域中找到解决方案的会议。会议的唯一合理目的是读取你正在处理的人的肢体语言。政治家、商人、扑克玩家、心理学家、医生等等,他们需要开会,因为他们必须读取我们的身体,而不仅仅是我们的思想。

在我们设计数据库模式时,我们真的关心莫妮卡的身体吗?嗯,这取决于情况,对吧?但让我们认真一点;我们不是为那个而付费。

对于一个有创造力的人来说,最好的动力就是看到他或她的创造力的成果。如果我没弄错的话,享受创造过程而没有任何成果是明显的精神疾病的迹象。一个健康而有创造力的人,比如软件工程师,希望看到他或她的努力如何转化为某种有价值的、最好是有形的东西。

会议几乎从不产生任何有形的东西,很少有有价值的东西。有时我们会有会议记录,但它们只是一张简短的纸,上面简要概述了我们讨论的内容。对于一个有创造力的人来说,这不是一个真正的“产品”。

因此,它们让我失去动力,因为我根本看不到我生命中的两个小时变成了什么。我们在那里并没有真正“创造”任何东西,我们只是“讨论”。请注意,我说的是会议,而不是像成对编程这样的协作工作。

你可能会说,有些会议确实产生了很棒的想法,这些想法是非常有形的结果。你可能会说,只有在直接面对面的环境中,这些想法才能诞生。你还可以说,很多明智的技术决策正是由于一种魔力的同向思考、同时在同一个房间里发生的协同作用而产生的。这个观点是有道理的,但我稍后会谈到这个问题。

我认为这是显而易见的。在会议的前几分钟,你会集中注意力;然后你开始查看Twitter动态和涂鸦。每个人都在做同样的事情,不是因为我们懒散,而是因为会议没有对我们的完全专注提出要求。

与此同时,当Monica在处理文件、提出意见和建议时,她会完全专注于结果,主要是因为没有其他人可以帮助她。她必须提交那个拉取请求,而我正在等她。她的专注程度与在会议上别人向她提出直接问题并要求她提供详细答案时一样高。

她的时间被优化以达到适当的结果,而其他人则在做其他事情。

另一方面,在会议上,我们最多只能稍微集中注意力。会议时间越长,我们的效率就越低。此外,与会的人越多,我们就越不在乎会议内容,越对我们的Facebook更新感兴趣。如果您至少在软件开发行业工作了几个月,我认为这对您来说并不令人惊讶。

这与之前的结论非常吻合。在项目中,会议是任何类型活动中最大的预算消耗者,仅仅因为他们支付在会议室里或在Skype会议上坐着的每个人,而他们所产生的结果几乎等同于一个人能够完成的工作。或者更少。

尽管这听起来很极端,但我必须说我认为会议是一种合法的“抢劫”项目的方式。大多数会议组织者(架构师、首席技术官、首席执行官、程序员等)并没有意识到这一点。他们相信他们谈得越多,就越是优秀的工程师。而他们的上司错误地欣赏下属这种活动。

我告诉过你要创建一个数据库模式的草稿。现在你找我开会,因为某些“方面”不清楚?你在哪里学过软件工程吗?你知道如何处理技术文档吗?你能用一种所有人都能理解并以书面形式回复你的方式写作吗?不行吗?现在你希望这个项目不仅为你的数据库模式草稿付款,还要为和你对话以及坐在我们旁边给他们的朋友发短信的其他人付款?你基本上想要剥夺这个项目的所有者。多一点也不少。

当控制时,质量会提高。当有人每天告诉我我的代码有错误,需要改进时,我的质量会提高。当没有人在乎我做什么或者我的结果有多好时,我的质量却会下降,无论我多么有自我激励能力。

会议促进团队的成就,抑制个人的成就。在会议结束时,往往不清楚到底是谁提出了一个好主意,谁付出了最大的努力。换句话说,在会议结束时,我不知道自己有多好。我还是一个月前的水平还是我成为了更好的工程师?

他们比去年夏天更频繁地微笑着问我“你怎么看?”这一定意味着什么,对吧?我相信你明白这不是一个认真的工程师所期望的反馈。

一个认真的软件开发者希望产生实质性的结果并获得实质性的反馈,比如金钱或代码审查。我想知道我的数据库架构草稿有什么问题以及我错过了什么。而且我希望这些被记录在某个地方。这是让我变得更好的方式,也是我学习和成长的方式。

现在,那么真正的创造力或者那个著名的“灵光一现”呢?有时候我们需要“大声思考”来发明一些东西,对吗?我们都知道当我们在研究和开发新事物时,面对面的互动有多么重要。如果没有会议,我们会处于什么地步?我们不能仅仅通过文件来工作;我们需要相互交流以释放我们的想法。这难道不是显而易见的吗?

我只有一个论点。爱因斯坦是在与同事开会时发明他的理论吗?我认为不是。而且他解决的问题比数据库模式设计大得多。

让我总结一下。开会是一项几乎不需要技能的活动,而将想法记录在文本和图表中则是一项更困难的工作。因此,训练并自律地处理文档工作,让初级员工享受他们的会议吧。

Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-28 at 15:12

sixnines availability badge   GitHub stars