所以如果你是程序员出身的技术领导，一定要区分 "自己" 和 "团队"，你要考虑的不是怎么让自己写得更快更好，而是怎么让大家都写得更快更好。只要你能持续提升整个团队的生产效率，你就是称职的，哪怕 "看不上" 其他人的代码，也得忍住。
在上面的例子里，如果你能把剩下 3 个程序员写代码的速度都提升到 1.5，代码质量都提高到 1.4，总生产率就有 1.5×1.4×3 = 6.3。这时候技术领导一行代码也不写，而且下属写代码的水平仍然赶不上自己，团队的生产率提高却是板上钉钉的事实――当然你还有其他办法，比如优化人员组合引入用生产率与自己相同甚至比自己更高的程序员，这样的效率更高了。
当然，"一行代码也不写" 多半是理想情况，许多时候技术领导还是必须要写代码的，因为软件开发终究是手艺活，大家认同的也是手艺。所以很可能会出现下面的情况：团队很缺某方面的开发经验或能力，除了技术领导之外暂时没人能对付；或者某个程序员不服气或者不理解某个决定，不能用头衔而只能用代码来说服和阐释……
除了这些 "必须" 的情况，我也主张技术领导 "应当" 写写代码。软件开发这个行业还太年轻，层级隔离做不到那么好，只说不写是找不到感觉的，而很多技术决策的依据正是这种感觉。所以我每次接手新的项目和团队，通常都要把代码全都看一遍心里才有底，自己提交几个功能才算找到了感觉。
这样看来，"技术领导要不要写代码" 这个问题没有统一的答案。所以有时候你不得不忍住 "让我来写" 的冲动，有时候你又不得不忍住恶心亲自动手。
就我个人而言，我觉得写代码而且不愿意放弃写代码能力的技术领导更可爱。程序员大多是单纯的，一起写代码，哪怕只写几个功能，也会告诉大家 "我不是来发号施令的，而跟你们一伙的"。
Read full article from 技术领导要不要写代码？_36氪
No comments:
Post a Comment