本文仅代表个人看法

前几天一位同事找我帮忙，正好遇上我在编码，他竟然感叹了一句：没想到你这PO还在写代码（看起来他的PO是不写代码的）！听到这话我的第一反应就是难道当了研发团队的管理者就不用写代码了吗？

编码

我从不认为研发团队管理者可以脱离代码，这些年的经历让我对这一点毫不怀疑。我干过基层研发，干过scrum master，也干过product owner，还干过技术教练，无论在哪个岗位上我都和代码发生接触。基层的时候我努力地写好自己的代码，当SM时带着团队写代码和Code Review，干PO时思考如何让业务领域照进代码实现，成为教练后办道场传播编码方法。写代码又苦又累还会沾上绵绵不绝的故障，可我为何还要坚持这样一件事呢？

知易行难，知行合一

首先这是工作的需要。我身边的研发团队还没有哪位管理者能够脱离技术、方案而只从事管理，现实中研发团队管理者的工作重心总处于业务和团队上。管理者单纯地依赖设计文档而不去读、写代码是很难深入业务核心，在无法深入理解业务核心的情况下对它提出的任何改进和修订的想法都是令人不安的，再遑论业务架构，这就是一种彻头彻尾的不负责任的流氓行为。

不读、写代码就缺少了与团队沟通的桥梁。团队每日的工作都是为了交付，任你说的天花乱坠最终还是要靠代码说话。靠代码说话就要求双方都在同一个语境下，能够清楚地表达逻辑流程。管理者并不一定要帮研发解决实际问题，但需要适时地提出实现参考或者代码问题从而引发研发的思考。如果对代码知之甚少，一旦“鸡同鸭讲”的次数多了，聪明的研发人员就自然而然地选择旁路你、疏远你，因此即使没有太多的时间去写代码，也至少应同步一些团队业务的流程、接口参数、数据库设计等。

更加重要的是，团队的代码还是管理者力量的源泉。团队成员往往会跟随管理者的想法，管理者的设计、架构甚至对于业务的理解都会体现在交付上。一名管理者要想名副其实地成为业务的权威、问题的专家就得真正地理解并帮助团队解决业务、代码中的问题。如果你不读、写团队的代码，力量的源泉是不会自动地出现在你身上的，毕竟你不是天生原力的绝地武士。

原力与你同在

曲不离口，拳不离手

这也是一种职业素养，研发团队的管理者本质上还是一名程序员，只不过站得略高、看得更多而已。既然以编码为生，就需要有应有的敬意，Bob大叔在他的《Clean Coder》中写道：

“想象音乐家是如何掌握演练技能的，他们靠的不是表演，而是练习。他们又是如何练习的呢？首先，表演之前，都需要经历过特别的训练，音阶、练习曲、不断演奏等。他们一遍又一遍地训练自己的手指和意识，保持技巧纯熟。”

弹钢琴

“每天我会练一两个卡塔，时间往往安排在正式投入工作之前。我可能会选用Java、Ruby、Clojure或其他我希望保持纯熟的语言来练习。”

代码这东西很神奇，长时间不接触就会生疏，尽管大脑中还留有概念和印象可动手写却非常不自在，甚至会觉得敲什么字母都不合适。更要命的是代码还在不断地进化，新的模式、技术、框架都在生长。除非下定决心不再从事编码工作，否则一旦脱离它太远太久就会出现再见面恍如隔世的感觉，完全看不懂那些新玩意。

相比恍如隔世的痛苦，保持对代码的熟络却花费很小，仅需要每天花上十几分钟最多半个小时，阅读一份团队代码，参加一次团队Code Review甚至重构一点团队实现。

最后当别人感叹代码在你的指尖流淌的时候，你大可以轻描淡写地一句总结：“无他，唯手熟耳！”