架构师是否必须编码，已经有了很多争论。为什么不尝试调试？
架构师喜欢做错事
架构师必须定期测试他们的假设，如果他们发现其中一些假设是错误的，他们必须感到高兴--这就是我们保持相关性的方法。
调试
系统告诉我们错误的一种奇妙方式是调试（包括运维问题的故障排除）。当现实偏离你的意图时，调试就会发生，也就是说，你在某些方面出了错。现在的任务是弄清楚你错在哪里了。这意味着调试中最快乐的时刻就是你发现你错在哪里的时候。
调试中最快乐的时刻是发现你错在哪里。
架构师通过调试系统，代替了（或补充了）编码，收获颇丰。
低开销
帮助开发者进行调试时，几乎没有设置或开销。开发者会有一个IDE和所有的工具设置，大多数可观察性工具由于其性质，是运行的子系统，不需要单独设置或配置。这意味着你可以快速进入调试环节，为团队提供价值。
专注于关系
架构的大部分内容都是关于线条的，也就是元素之间的连接和依赖关系。而 "盒子"，即单个组件，通常是经过良好测试的，不太可能成为问题的来源。这就是为什么许多错误，特别是运行时问题，是元素之间复杂的相互作用的结果。不出所料，这也是系统架构的领域。现代架构师不需要告诉开发者每个方法允许多少行代码，或者什么时候使用Singleton。相反，架构师关注的是整个系统的结构，并确保在面对负载、需求或环境的快速变化时的可靠运行。
小变化，大影响
调试工作的结果通常是大量的思考，然后是一个小的代码或配置变化。这就是为什么它是架构师的一个理想任务。对架构师来说，编写几行代码并不是最有价值的活动。但了解系统结构和隐藏的依赖关系才是最重要的，而调试就是关于这一点。
超越层次
架构师电梯的关键概念是跨越层次，从IT和商业战略一直到技术细节。调试确实需要你深入研究。最伟大的调试故事之一是Jeff Dean和Sanjay Ghemawat通过观察二进制格式的数据来检测硬件相关的故障。
偶然性
作为架构师，我们喜欢结构化的方法和思维。调试的工作方式正好相反：系统把你带到一个你没有充分注意的地方。因此，调试是了解系统角落的好方法，否则你可能会忽略这些角落。
即时增值
编码对架构师来说是一项有用的工作，但它也与开发人员的任务和性能指标相重叠。编码架构师可以被看作是对团队的帮助，但也可以看作是越过了自己的界限。相比之下，对调试或生产问题的帮助，几乎总是受欢迎的。而且这肯定比管理层要求更新故障信息要好。帮助开发人员排除故障可以为你在机房赢得一些非常有用的友谊。