首先沟通是工作的基本技能，不能因为程序员大部分时间面对电脑，而去排斥沟通工作。另外，所有伟大的软件都是由团队开发完成，即使个人的能力在强，也无法独自完成。做一个技术极客虽然很酷，但是带领一个团队才能完成更大的目标。
TL 编码时间下降后的困惑
成为TL后，面对工作内容的转变，的的确确会产生困扰。
作为开发时，绝大部分工作是写代码，你可以准确量化自己的工作。例如今天写了上千行代码、完成了几个Story、修复了几个 Bug。你对自己的工作成果非常清楚。这是可以量化的工作给你带来的踏实感。
当你成为了 TL，会发现一天紧张忙碌的工作后，自己好像啥也没干。今天开了一个漫长的会议讨论清楚了几个接口；和架构师一起review了一个方案；评估了一个需求的工作量；帮助团队成员解决了几个难题；和团队几个核心成员谈了未来的发展。糟了，一天下来我一点代码也没写！
这些工作和写代码比较起来，有两个差异：
- 工作不落地，写代码心里更踏实
- 很多工作无法量化，短时间也看不到效果
第一问题来源于工作内容的改变。TL承担了大量的管理工作。可能一天只写了很少的代码，甚至没有碰代码。但是由于思维的惯性，觉得只有写代码才是落地的工作，才是有意义的工作。
当你成为TL后，意味着你的职责已经发生了变化。写代码只是你的职责之一。更重要的是带领整个团队完成系统开发。如何为团队铺路，提升团队效能，才是你更为重要的工作。不要只盯着自己写的代码量。
再看第二个问题。很遗憾，管理的工作很难去量化。通过精细化管理，收集数据，统计指标，能在一定程度上反映出管理的提升。但这只是管理成果的凤毛麟角。更重要的是，影响指标的杂音太多。指标更大的作用是帮助我们发现问题。
通过指标能在一定程度上反应管理的效果。但需要深入思考，综合各个指标，以及可能的原因，找到解释的通的影响指标的逻辑。否则很容易通过数据推导出错误结论。
其实只要你身处团队之中你就能切身感受到管理带来的成功。比如团队成员做事情更让你放心、更乐于分享讨论技术问题、code review 发现的问题越来越少、团队做事情越来越有条理等等。
TL 如何避免远离代码
编码既然已经不再是 TL 的主要工作，那么 TL 是否可以长时间不写代码？
答案一定是否定的。
TL 为什么要写代码？
TL 非常有必要写代码，原因如下：
- TL 的根是 Tech，TL 的管理工作以技术为根基
- 只有自己完整的开发一个story，才能切身体会到自己制定的流程、规范是否合理
- 写代码过程中可以找到团队痛点和改进方向
- 写代码过程中可以了解到团队成员的代码质量
- 通过开发一个story，熟悉代码实现，面对客户的问题更加从容
TL 如何让自己留有写代码的时间
你可能会说，我也想写代码，但管理工作太多了，真的没时间写！
管理工作有个特性是永远做不完。想给出问题的最佳答案，需要反复推倒重来，穷尽可能。将管理工作做好和做到极致，工作量可能是数量级的差距。
在繁重的管理工作之下，如果 TL 不刻意给自己预留写代码的时间，那么必将会被管理工作淹没。
任何事情都是有粘度的。当你一段时间不写代码后，会愈发的不想写代码。当你意识到问题的时候可能已经脱离技术很久。
建议 TL 们每天都给自己留一些时间写代码。强迫自己停下手中的管理工作去写代码。如果工作时间真的太忙，也要花一些业余时间写点代码，让自己不手生。
TL 写什么样的代码？
TL 时间有限，写代码是要有选择的。TL 可以考虑如下几种开发：
- 项目的架构代码
- 底层核心代码
- 点数不大、不被其他需求依赖的 Story
- 使用了想要了解的技术栈的 Story
前两种情况一般出现在项目筹备期，或者刚起动项目时。TL 需要完成架构的基础代码，基于方案完成核心代码。如果架构是稳的，项目稳了 8 成。这些工作的完成情况决定了项目全面铺开时团队的速率和质量，非常之重要。TL一定要亲自把控和开发。
开发点数不大的 story 是为了让 TL 从头到尾开发一个story，找到工程实践可以提升的地方。同时 TL 可以借此机会熟悉业务代码。
点数一定不要太大，因为 TL 写代码的时间有限，可能3天的开发，TL需要开发一周。点数太大的卡，不能保证在迭代结束时开发完成。TL 开发的 Story 一定不要对别的需求开发产生依赖，避免 Block 他人工作。
最后，如果项目中有TL 不了解的技术栈 ，那么可以挑选相关的 Story 开发。任何技术都是在实际使用后才真正掌握。TL 通过这种方式在拓宽自己技术广度的同时，也掌握的更为牢固，为未来输出扎实的技术方案提供弹药。
Tech Lead 需要掌握技术到什么程度？
这个问题可能每个TL都会时不时问自己。
作为 TL，永远不要觉得自己的技术已经够用。即使你的技术已经能够完全驾驭你现在的工作，但谁能知道明天你的工作是什么呢？你需要不断拓宽自己的知识领地，不断加深自己的技术深度。
我们工作的内容经常会发生变化，碰到不熟悉的技术栈是常有的事。不同项目对同样技术要求的深度也不一样。
面对这种情况，TL 应该学习技术到什么程度呢？每门技术都需要精深吗？
显然这是不可能的，因为人的精力有限。
保持足够的技术判断力
这个问题的答案是，你掌握的技术能够给你足够的技术判断力。
这个答案来自公司内训老师，我深以为然。
技术判断力是工作中运用技术做出判断的能力。例如下面这些例子：
- 技术方案如何选择
- CodeReview 如何给出建议
- 问题的定位
- 工作量评估
项目不同，采用的技术也不同。如果不熟悉的技术限制了你的技术判断力，那么你需要去学习这门技术，直到足以支撑你给出合理的技术判断。
另外，由于不同项目对同样技术运用的深度也不一样，TL应根据需要深入学习。直到你能给出合理的技术判断。
保持技术关注度
在项目范畴外，TL 需要了解更多技术栈。只有这样，才不会被现有技术栈所局限。当新问题出现时，才会有新的思路，采用更优的技术方案解决。否则永远都是用老的技术栈原地踏步，明明有更优的解决方案，却下大力气在陈旧技术上持续投入。技术落后意味着要自己、团队、公司要挨打、要被淘汰。
每个团队都在强调技术创新。技术创新的前提是你得知道新技术。你能否有创新，基于你的技术见识度。
TL 需要一直关注新技术，思考匹配的问题。只有这样，你的技术嗅觉才能敏锐察觉到创新的机会。
总结
TL 编码量的大幅下降，确实会让你适应一阵子。但是你很快会发现不写代码的日子也不错。等等，千万不要有这种想法。为了让自己不远离技术，保持足够的技术判断力和创新能力，你依旧需要写代码。但是受制于精力，你需要选择性的写代码。有时你需要要刻意给自己留出编码时间。Tech Lead 的根基是Tech，也是你安身立命的东西，请永远都不要停止编码。
