在一个科技公司里，软件技术经理用在编程上的时间应该不低于总工作时间的30%。无论是管理一个团队，还是一个分部，还是整个公司，当技术经理用在编程上的时间低于30%时，他执行职责的能力会发生严重退化。
　　我的这个断言可能跟那些我看到的想成为团队首领的软件程序员们期望的情况完全相反。每次晋升，程序员们都期待花在编码上的时间会大幅度减少，当从“leader”爬到“经理”职位时，应该彻底脱离编码活动。而且，他们期望以一种“动口/眼不动手”的方式来保持对代码库的熟悉。再上级的领导跟编码完全没关系了(如果有的话)。
　　大概一年前，当时我的时间被越来越多的其它事情占用，例如招聘，管理，开会等；我发现，作为一个技术首领，当花在编程上的时间低于某个比例后，管理效果和工作效率会出现问题。之前我写过一篇短博客阐述过这种体验和观点，但没有展开具体的描述。这里，我将会对这个观点展开更详细的论述。
　　为什么要坚持编程活动
　　很多人认为，做为管理者，应该退出战斗第一线，专注于大战略和管理工作。当然，管理者把大部分的时间用在这种事情上是应该的。但是，在我们这样一个行业里，因为我们允许或要求管理者几乎不再去编程，现实让我们付出了沉重的代价。一旦一个人停止编码，他和程序员们关心的事物之间的重要联系会退化。当这种情况发生时，决策，计划和干群关系会出问题，从而瓦解了将技术人员提升到管理职位的良好愿望基础。
　　项目开发评估能力
　　程序员的百宝箱中重要的一个绝活是估计工期。如果没有准确预估的能力，整体计划是不可能正确的出台的。大家也知道，做为一个族群，程序员们对工期的估计是臭名昭著的。糟糕的不能再糟，事实上，当从程序员口中得到一个预估的数字后，公认的方法是将它乘以二。通常，程序员都会对开发工作抱有非常乐观的态度，但如果我们使用“estimate traction”理论，会发现，编程活动表现出特别易变的特征。因为我可以用很多方法实现一个功能，当我们在还没有深入细节之前，我们的估计是不可靠的。
　　技术债务
　　另外一个事情是，技术经理必须对技术债务给项目造成的影响掌握第一手的资料。如今，技术债务这个术语非常流行，常被用来当作争论是优先开发新功能还是先重构老代码的弹药。对“技术债务”这个词的内涵熟悉的人通常容易发起论战。作为技术经理，你不仅仅是要熟悉这个概念，它们会在你判断何时偿还技术债务的决策中起直接作用。经常写代码的经理拥有更多更有价值的信息来判断何时/如何做出这样的决策。
　　知情的连续性
　　我并不是随意选择30%的比率的。我是基于自己的经验，将足够的时间参与到开发活动中，你很容易能时刻掌握代码库的任何变化。如果时间太少，你对开发动态的掌握是断断续续，无法连成线。一旦断了线，我需要重新理顺脉络，由此得到的惩罚是浪费了额外的时间。
　　分担责任
　　作为负责人，你不可能让所有决策都由你制定或由你批准。但你需要了解所有决策的前因后果和背景知识，来辅助这些决策。终，你要为这些决策的后果负责，你对项目情况的掌控能力要能匹配你的这份责任。
　　积极参与编程赢得团队尊敬
　　大家需要明白：要想成为一个成功的经理，你需要为团队成员提供服务，促进开发，确保他们完成任务。我曾在一篇博客里写过如何诊断和修复经理们有问题的干群关系。但是对于的管理程序员来说，你需要热爱编程。因为你的团队在编程，如果你在编程上做榜样，他们都会对你肃然起敬。