写点什么

团队管理者应该参与编程吗?

作者:刘华Kenneth
  • 2024-03-09
    广东
  • 本文字数:2215 字

    阅读完需:约 7 分钟

团队管理者应该参与编程吗?

01 为什么团队管理者也要编程?


即使是一家科技公司,很多程序员变成团队管理者后,就不编程了。


最近,公司管理层统计内部 Github 的数据,发现在全公司内提交代码的员工比例并没有想象中高。有些部门开始以“工程师文化”为名倡导更多人应该参与编程,包括团队管理者们。


我作为技术总监之一,最近也参与了团队内某个需求的编程,目前已经上线。


我的主要目的是体验一下团队成员,特别是程序员的真实工作环境,从而和团队共情,更好地参与到团队的技术讨论,也可以和团队一起改进流程和工具,创造更好的工作环境。


02 我的编程体验


作为团队管理者,因为日常管理工作占据了大部分时间,我确实有一段时间没有参与编程工作了。那么,我面对的第一个困难就是要重新搭建开发环境。这往往需要花费数天的时间安装各种软件、申请权限和搭建环境。


得益于团队引进了 DevContainer 和 Coder,让我可以在几分钟内获得一个完全配置好的开发环境(Web IDE),得以立即开始编程工作。


Coder 提供了在线开发体验。通过与 DevContainer 集成,它提供团队一致的开发环境,无论成员使用哪种操作系统和设备。团队的程序员可以通过 Coder 用简单几步操作即可创建工作区来开始编程工作。


即使是新加入的程序员,只要获得 GitHub 的访问权限,就能在几分钟内启动编程工作。这也特别适合我这样偶尔参与编程工作的。


也因为团队在 Github 项目里的 README 给力,我很快可以在 Coder 里获得最新的代码和运行测试。也很快找到在哪里修改代码满足需求,并做出初步设计和团队讨论。然后开始编程和调试。


这个过程的体会是:


1. 编程所需要的时间模式和管理工作完全不一样


编程需要一大段专注的时间。管理工作很多时候是开会,时间比较碎片,很多时候需要一心多用。对于团队管理者们来说,如何找到一大段专注时间,是一大挑战。所以编程工作对于大多数团队管理者来说,确实只能偶尔为之,以体验为主,不能成为日常工作之一;


2. 大多数团队管理者对编程已经非常生疏,编程速度慢。由于已经离开编程工作有一段时间了,更别提技术日新月异,有很多新的技术、框架、语法和编程范式需要重新学习,大多数团队管理者已经从原来的编程高手蜕变成“菜鸟”。一个十几年前的 Java 程序员,不管当时编程能力多厉害,面对 Lamda 和 Stream 这类新的 Java 语法,也是一脸懵。而我是从 Java 切换到 Python 的,跟 Python 确实不熟,要熟悉 Python 的语法和各种包的用法,需要一些时间。编程过程中,你一定会被某些小问题卡住,而这一卡,可能就是一两天时间,这期间包括针对这些问题的各种搜索和尝试。


3. 调试和测试永远是编程的难点。如何获取程序执行过程的中间数据,是调试的关键。是否写自动化测试,也是一个很令人纠结的过程。理论上,任何变更都应该写自动化测试,但是要通过编程构造输入数据和验证程序输出数据所需要的时间和精力,远远超过手工测试。


简单来说,对于我来说,编程过程会比较慢,速度肯定远比不上团队里的其他程序员。


这个过程,也难免需要打扰到其他程序员。需求分析、设计、编程、调试、测试、部署、上线,涉及到多个过程和工具,我们的文档再完整,也不可能做到面面俱到,有一些测试需要的系统登录信息,也不适合以公开文档的形式共享,有些细节还是需要询问其他程序员然后记录在自己的小抄里。


和其他程序员进行结对编程,可能也是一种方式,只要你不怕暴露自己在编程上的生疏和新技术的空白。当然,这可能会占用团队更多的时间。


另外,作为一个曾经的程序员,这个过程也能找回我们的初心,从“本我”的角度,相对于跟人打交道,我们确实更擅长和更享受与代码为伍。哪怕过程中遇到各种各样的技术挑战,也会享受不断尝试和找到解决方法的过程。


03 温馨提示


在这里,基于我的体验,给要参与编程的团队管理者们一些建议:


1. 不要开发有时限要求的关键需求


由于团队管理者们比较难有一大段的专注时间,加上编程速度会比较慢,应该选择没有时限要求的边缘需求,这样时间上会比较从容。参与的重点是体验和共情,不是交付的结果。


2. 遵循团队的开发流程和规范。这些都是团队长期优化和调整的结果,哪怕一开始觉得不顺手或感觉不对,也应该先尊重历史,把整个过程体验完了,再和团队一起探讨改进方案。


3. 作为一个“生手”,团队管理者们的编程能力可能比不上团队的程序员,写出 bug 的概率也会比较高。这也是为什么要选择没有时限要求的边缘需求,需要在更从容的环境下对程序做更充分的测试,也应该让团队的程序员评审代码和测试。确保交付质量。


04 总结


作为科技公司的团队管理者,如果有机会参与编程,是可以重新体验作为工程师的初心,也能深入理解团队程序员日常工作的过程和痛点,从而和团队一起改善流程和工具,创造更好工作环境。


但由于写程序和管理工作的时间模式完全不一样,团队管理者们可能只会有非常有限的时间进行编程工作,加上编程速度可能不高,要避免开发有时限要求的关键需求,从而可以从容体验也避免写 Bug,给团队添乱。


05 番外


技术团队管理者参与编程有另一个额外好处,就是能让团队里的技术大牛服你。


在我当初空降到云平台团队作为技术总监时,我可以感觉到团队里某些资深工程师觉得我的出现有点多余,特别是在一开始的时候,我对云平台和团队在做的东西需要一个熟悉的过程。


随着我逐渐融入到团队里,并为大家的工作环境带来改变,情况好转了。但真正折服他的时刻是我亲自参与了某个模块的编程以后。他说对我不是一个“离地”的团队管理者这一点印象深刻。


觉得文章不错,顺手点个点赞收藏转发给朋友们吧。



发布于: 刚刚阅读数: 5
用户头像

刘华Kenneth

关注

敏捷、精益、DevOps专家 2017-10-19 加入

著有书籍《猎豹行动:硝烟中的敏捷转型之旅》《软件交付那些事儿》;《图数据库实战》译者之一;敏捷、精益、DevOps专家;公众号“敏于思 捷于行”博主;曾在国内多个大型论坛发表过主题演讲;就职于世界500强银行。

评论

发布
暂无评论
团队管理者应该参与编程吗?_编程_刘华Kenneth_InfoQ写作社区