Team Leader究竟要不要写代码?

在互联网行业，程序员常常面临一个重要的抉择：是继续深耕技术，成为一名架构师，还是转型为研发管理者？

这个问题涉及到个人职业规划、兴趣爱好以及对未来的期许。

今天，不念跟你将探讨这个问题，并对程序员们提供一些建议，希望能帮助大家更好地理解自己的职业发展路径。

不少人的认知里，现在 996 疯狂写代码，好像是为了日后可以不必再写代码。

不管是架构师、资深专家，还是研发部门管理者，他们的工作目标主要依据是组内程序员更高效的工作效率、更好的投入产出、项目进度没有风险。

很多程序员都想成为「不写代码的程序员」。

从技术视角来看，作为程序员的你天生就带有工匠精神，并不迷信管理自己的人，但是会尊重指导自己的技术牛人。

遇到问题讲不通就来一句「Talk is cheap, show me the code」，代码亮出来就知道能不能让人信服。

以后无论你的职业目标是永远作为程序员还是架构师、研发管理者，都不要轻易离开一线技术领域。

因为脱离技术去管理好程序员，是很困难的。

远离技术，你只会拉通对齐 ppt

当你离开技术，不再编码的时候，慎重啊，这决定就像高考后把数学、生物、地理书都扔了一样，一旦放手，再想捡起来就难比登天了！

离开了编码的战场，渐渐地对代码、技术、产品状态和团队研发状态的理解就会跟团队技术成员产生偏差。

就好像团队的程序员说用 Serverless 无服务架构，你以为是去掉一些服务节点；Redis 分布式锁续期使用看门狗机制，你以为是哈士奇咬开锁跳飞机。

久而久之，你无法在技术细节上给予技术指导的能力，丧失了在专业问题上提出可落地接地气的解决能力。

只能通晒、拉通、颗粒度对齐；遇到问题只会说「问题的关键是要找到关键的问题，大家解决问题去吧。」

于是乎，你只能在短期无法验证对错的大战略方向上提意见，参加会议、研究一套如何像流水线监视程序员产出的人，在汇报上寻找存在感！

这时候，你不再是团队的导师，而是一个只能靠管理职位权力来维系关系的雇佣关系的人，即使你在团队里面叫他们「兄弟」，成员并不服气。

技术能让你更容易做好管理

需要明确的是，技术和管理并非非此即彼的选择。许多成功的架构师和研发管理者在职业生涯中都保持着一定程度的技术深度，并且能够在技术和管理之间灵活切换。

在实践中，我们可以看到，那些既懂技术又懂管理的人才往往更受欢迎，因为他们能够更好地理解团队的工作，并且能够为团队提供全面的支持和指导。

有人会说：“年纪大了，时间不够用；精力花在管理上了”

我想说的是做好技术很难，需要保持持续学习的心；但是在做好技术的前提下却比较容易做好架构和管理工作。

程序员编程是我们的本职工作，也是我们当年白手起家吃饭的手艺，作为团队的领导者，我可以利用我的技术经验来指导团队成员，并为他们提供技术上的支持和指导。

我的技术背景使我能够更好地理解团队成员的工作，并提供针对性的建议和解决方案，从而提高团队的效率和生产力。

作为一名技术架构师，我可以通过我的技术专业性来赢得团队成员和其他利益相关者的信任和尊重。我的技术背景使我能够更好地理解项目需求和挑战，并为团队制定合适的解决方案，从而提高项目的成功率和质量。

保持技术的锐度

我们只有通过不断地学习、实践和探索，我们可以保持自己的技术锐度，成为领域内的专家。

作为架构师，深厚的技术功底将帮助他们设计出更加稳健、高效的系统架构。

而作为一名研发管理者，技术深度则可以帮助他们更好地理解团队成员的工作，并为团队提供技术上的支持和指导。

那么，读到这篇文章的朋友，你有什么观点？欢迎留言我们一起探讨。