本文的作者Eliot Horowitz是MongoDB的创始人和技术总监。
　　在一个科技公司里，软件技术经理用在编程上的时间应该不低于总工作时间的30%。无论是管理一个团队，还是一个分部，还是整个公司，当技术经理用在编程上的时间低于30%时，他执行职责的能力就会发生严重退化。
　　我的这个断言可能跟那些我看到的想成为团队首领的软件程序员们期望的情况完全相反。每次晋升，程序员们都期待花在编码上的时间会大幅度减少，当从“leader”爬到“经理”职位时，就应该彻底脱离编码活动。而且，他们期望以一种“动口/眼不动手”的方式来保持对代码库的熟悉。再上级的领导就跟编码完全没关系了(如果有的话)。
　　大概一年前，当时我的时间被越来越多的其它事情占用，例如招聘，管理，开会等;我就发现，作为一个技术首领，当花在编程上的时间低于某个比例后，管理效果和工作效率就会出现问题。之前我写过一篇短博客阐述过这种体验和观点，但没有展开具体的描述。这里，我将会对这个观点展开更详细的论述。
　　为什么要坚持编程活动
　　很多人认为，做为管理者，应该退出战斗第一线，专注于大战略和管理工作。当然，管理者把大部分的时间用在这种事情上是应该的。但是，在我们这样一个行业里，因为我们允许或要求管理者几乎不再去编程，现实让我们付出了沉重的代价。一旦一个人停止编码，他和程序员们关心的事物之间的重要联系就会退化。当这种情况发生时，决策，计划和干群关系就会出问题，从而瓦解了将技术人员提升到管理职位的良好愿望基础。
　　项目开发评估能力
　　程序员的百宝箱中最重要的一个绝活就是估计工期。如果没有准确预估的能力，整体计划是不可能正确的出台的。大家也知道，做为一个族群，程序员们对工期的估计是臭名昭著的。糟糕的不能再糟，事实上，当从程序员口中得到一个预估的数字后，公认的方法是将它乘以二。通常，程序员都会对开发工作抱有非常乐观的态度，但如果我们使用“estimate traction”理论，就会发现，编程活动表现出特别易变的特征。因为我可以用很多方法实现一个功能，当我们在还没有深入细节之前，我们的估计就是不可靠的。

本文的作者Eliot Horowitz是MongoDB的创始人和技术总监。
　　在一个科技公司里，软件技术经理用在编程上的时间应该不低于总工作时间的30%。无论是管理一个团队，还是一个分部，还是整个公司，当技术经理用在编程上的时间低于30%时，他执行职责的能力就会发生严重退化。
　　我的这个断言可能跟那些我看到的想成为团队首领的软件程序员们期望的情况完全相反。每次晋升，程序员们都期待花在编码上的时间会大幅度减少，当从“leader”爬到“经理”职位时，就应该彻底脱离编码活动。而且，他们期望以一种“动口/眼不动手”的方式来保持对代码库的熟悉。再上级的领导就跟编码完全没关系了(如果有的话)。
　　大概一年前，当时我的时间被越来越多的其它事情占用，例如招聘，管理，开会等;我就发现，作为一个技术首领，当花在编程上的时间低于某个比例后，管理效果和工作效率就会出现问题。之前我写过一篇短博客阐述过这种体验和观点，但没有展开具体的描述。这里，我将会对这个观点展开更详细的论述。
　　为什么要坚持编程活动
　　很多人认为，做为管理者，应该退出战斗第一线，专注于大战略和管理工作。当然，管理者把大部分的时间用在这种事情上是应该的。但是，在我们这样一个行业里，因为我们允许或要求管理者几乎不再去编程，现实让我们付出了沉重的代价。一旦一个人停止编码，他和程序员们关心的事物之间的重要联系就会退化。当这种情况发生时，决策，计划和干群关系就会出问题，从而瓦解了将技术人员提升到管理职位的良好愿望基础。
　　项目开发评估能力
　　程序员的百宝箱中最重要的一个绝活就是估计工期。如果没有准确预估的能力，整体计划是不可能正确的出台的。大家也知道，做为一个族群，程序员们对工期的估计是臭名昭著的。糟糕的不能再糟，事实上，当从程序员口中得到一个预估的数字后，公认的方法是将它乘以二。通常，程序员都会对开发工作抱有非常乐观的态度，但如果我们使用“estimate traction”理论，就会发现，编程活动表现出特别易变的特征。因为我可以用很多方法实现一个功能，当我们在还没有深入细节之前，我们的估计就是不可靠的。