首先推荐两篇王垠的博客文章：
今天回看了一遍王垠的这两篇文章，比较庆幸的是，自己在平日的工作中，很少在无意间触犯到王垠提到的这些礼节问题。
会突然想起这个话题是因为工作中的一点小事，也挺有意思。起因是我擅自 merge 了没有经过 review 的代码，我的同事就开始在群里批判我的代码，也许是他觉得不经过他 review 就合并代码的行为，伤到了他在团队中的尊严和地位。
我现在在一个 web3 项目的开发团队工作，团队总共也就四五个人，内部管理却非常混乱，这是我在之前的工作中没有遇到过的。不过说实话我之前的工作经历不太够看，没有什么参考价值，所以我总结不出什么有用的结论。
要我对比的话，现在的工作和以前的工作，工作方式上最大的区别，在于分配任务的粒度不同，或者说分配到个人头上，负责的事情大小不同。
比如我在 Onchain 工作的时候，需要开发 Solidity 合约，来支持我们的分布式文件系统对 EVM 链的兼容，那么这件事情就是我在做，有人 review，但实际上整个 合约仓库 的代码只有我一个人提交（这里不是在强调提交人数的问题），在这样的模式下，自然也就不存在现在遇到的什么代码质量之类的问题。
（Onchain 这家公司已经解散了，当时项目的代码并没有开源，现在的代码仓库是我私自备份下来的，两年过去了，应该不会有什么风险吧）
再比如我在 Fusionist 工作的时候，整个 Endurance Network 的网络是我一个人启动并维护的，没出过什么问题。主网上线的时候有一个专业的运维同事帮忙开服务器、配置 Docker 之类。
（我已经离职了说出来应该没事吧）
包括更早先的工作经历，不管是我自己还是同事，直观感受上就是每个人都会负责某一块的业务，对整体业务负责而不是对某个具体的开发任务负责，个人的职责相对明确，在负责事情的时间长度上，都是几周到几个月为单位的，所以倒是没有出现过管理混乱的情况。
现在的工作模式是不太完整的 Scrum 风格，每个任务都是两到三天的开发周期，也就是小的开发任务，这些开发任务一定程度上是不区分业务线（代码仓库）的，开发人员会随机参与到不同的事情上。每个人都是在对自己的开发任务（PR）负责，而不是整个仓库负责。这种模式下，每一个开发任务都会有不同的负责人，造成感官上是比较混乱的。
侧面来对比的话，我之前的工作，如果某个人离职，是需要做很长时间工作交接的，因为需要一段时间来让别人接手。现在的工作，如果某个人离职，其实也没啥需要交接的，最多也就两三天的任务内容。不知道是不是远程工作的缘故，让公司被迫选择这样的管理方式。
我的大老板曾经把这种工作模式上的差异，总结为中国式的管理风格和欧美式的管理风格之间的差异。
我只是个普普通通的开发人员，没有管理经验，也不懂这些管理模式什么的，并不想也没什么机会需要我去思考这些问题。只是现在有点能感受到，其实管理本身是一门学问，挺大的学问……