本文作者EliotHorowitz是MongoDB的创始人兼技术总监。在科技公司，软件技术经理至少要花30%的总工作时间在编程上。无论是管理团队、部门还是整个公司，当技术经理花在编程上的时间少于30%时，他履行职责的能力就会严重下降。我的断言可能与我对希望成为团队领导者的软件程序员的期望完全相反。随着每一次晋升，程序员都希望花在编码上的时间会大幅减少，并且当从“领导”职位攀升到“经理”职位时，他们应该完全脱离编码活动。此外，他们希望以“闭嘴/闭眼”的方式保持对代码库的熟悉。下一级的领导与编码无关（如果有的话）。大约一年前，我的时间被越来越多的事情占用了，比如招聘、管理、会议等等；我发现作为技术负责人，当花在编程上的时间低于一定比例时，管理效能和工作效率就会出现问题。我之前写过一篇关于这段经历和观点的简短博客，但没有详细描述。在这里，我将更详细地讨论这个观点。为什么要坚持编程活动很多人认为，作为管理者，应该退出战斗的第一线，专注于大战略和管理。当然，管理者应该把大部分时间花在这些事情上。但在像我们这样的行业中，由于我们允许或要求经理们几乎不再编程，现实付出了沉重的代价。一旦一个人停止编码，他与程序员关心的事情之间的重要联系就会恶化。当这种情况发生时，决策、计划和干部关系就会出现问题，破坏将技术人员提拔到管理职位的良好基础。程序员百宝箱中最重要的技能之一就是估算工期。没有准确估算的能力，就无法正确地引入整体方案。我们还知道，作为一个群体，程序员因对构建时间的估计而臭名昭著。不能更糟了，事实上，当你从程序员那里得到一个估计数字时，公认的方法是将它乘以二。通常，程序员对开发工作抱有非常乐观的态度，但如果我们使用“估计牵引力”理论，我们会发现编程活动表现出特别不稳定的特征。因为我可以通过多种方式实现一个功能，当我们没有深入细节时，我们的估计是不可靠的。关于技术债的另一点是，技术经理必须掌握技术债对项目影响的第一手资料。技术债务一词近来非常流行，并且经常被用作关于是优先开发新功能还是先重构旧代码的争论的弹药。熟悉“技术债务”一词含义的人通常是最有可能发起辩论的人。作为一名技术经理，您不仅需要熟悉这些概念，它们在您决定何时还清技术债务方面发挥着直接作用。经常编写代码的经理在何时/如何做出此类决定方面拥有更多有价值的信息。知情的连续性我没有随意选择30%的比例。根据我自己的经验，只要有足够的时间参与开发活动，您就可以轻松地了解代码库的任何更改。如果时间太少，对发展动态的把握就会断断续续，无法连成一线。一旦断开连接，我需要重新连接，而这样做的代价是浪费了额外的时间。共同责任作为所有者，您不能让您做出或批准所有决定。但是您需要了解所有决策的背景和上下文以帮助做出这些决策。最终，您要对这些决定的后果负责，您对项目情况的控制应该与您的责任相匹配。积极参与编程，赢得团队尊重每个人都需要明白：要成为一名成功的管理者，你需要为团队成员提供服务，促进发展，并确保他们把事情做好。我曾经写过一篇关于诊断和修复经理之间有问题的关系的博客。但是对于最好的管理程序员来说，你需要热爱编程。因为你的团队是编程的，如果你在编程方面做出了榜样，他们就会尊重你。达到30%的门槛尽管我尽了最大的努力，但要保持30%的编码时间，我仍然有很多障碍。包括以下内容：大量工作：在创业公司，你总是有无穷无尽的工作要做。甚至在公司有了规模，发展壮大之后，很多重要的事情如何分清轻重缓急，也是一个考验。技术经理有很多职责，会占用他70%的时间。以下是一些：领导和照顾团队：这是技术经理的首要任务。你不能再只对自己的工作负责，你有责任让你的团队保持最佳工作状态。指导团队任务、解决纠纷以及弄清楚如何优化工作条件以提高工作效率和舒适度都需要时间。做决策：随着权限的增加，技术经理需要花更多的时间在各种战略规划和规划上。起初，可能只是一些技术决策，但后来，产品开发和竞争战略问题将占据很大一部分。招聘：经理、董事、副总裁和CTO都需要建立自己的团队，有时需要很快。一个好的招聘人员可以走很长的路，在这种情况下，技术经理是无可替代的。一个好的技术经理会积极与上级保持沟通，不断推荐自己团队中的优秀人才。客户：随着技术经理权力的增长，他们经常出现在公众视野中。他们将被带到一个“推介会”，期待他带来一些深度。或者当重要客户不高兴时被叫去灭火。公共关系：高级技术经理会把部分时间用于公开演讲、撰写博客或在报刊杂志上发表文章。无论你在这些活动中投入多少，写作、编辑、排练、旅行、参加活动等都需要时间。收回时间：我上面提到的活动都是技术经理应该投入时间的事情。以下是我从经验中发现的一些陷阱，这些陷阱阻碍了我尝试保持20%***的编码时间，并且今天仍然站在我面前，阻止我回到我的30%目标。不要说不：高成就意味着努力工作；但是，安全起见，技术经理最重要的职责之一就是在您的团队负担过重或接近负担时说不。如果此时你不拒绝，其他人将开始评判你的计划和时间表承诺。会议：关于如何有效召开会议的想法有很多，而且各有各的原因。我在会议上浪费的时间比我在职业生涯中浪费的时间还多。尤其是经常性的面谈或出席会议，必须由组长参加。失败的策略在弄清楚如何让我的编码时间回来时，有很多事情都行不通。少睡：虽然这个方法对我有巨大的诱惑力，但实际上，牺牲睡眠时间并没有什么效果。您的大脑需要休息，睡眠不足会影响您的情绪并降低工作效率。只看头文件：我认为这种方法行得通，但实际上，只看提交的C++代码的头文件对你的管理帮助不大。具体：作为团队负责人，你可能只专注于代码库中的一个项目，但对于主管或更高级别的人来说，你应该熟悉并理解你所负责的一切。托付：有时候为了多做一些工作，有些事情会随意交给别人，但实际上，有些事情，比如写报告，你必须认真索取。成功的策略尽管有很多死胡同，我还是发现了一些成功的策略：时间安排：我的日程安排中几乎没有时间是预先分配好的。当您考虑它时，它也很明显。所以我专门留出一些时间段来编程。在实践中，这些时间段经常被重新调整，虽然每周只挤出8小时，但效果完全不同。委派：委派需要技巧，尤其是当你对如何执行和执行任务有很强的想法时。管理者反对委派任务的理由有很多，但实际上每一个理由都应该被看作是存在的需要解决的问题，而不是不可逾越的障碍。没有什么比让您信任的人为您主持会议更能节省编码时间的了。工作时间：把时间分段，尽量避免在工作时间被打扰。在这些时间段之间的时间里，我会做一些不重要或需要长期关注的事情。***提示以下是一些技术经理的经验提示，他们发现自己试图达到30%但无法接近：学习如何阅读代码。这是与编写代码完全不同的技能。指定会议流程并保持对会议流程的控制。不要参加任何计划外的会议。使用一台好的电脑。你喜欢MacBookAir吗？不，不要使用它。知道如何访问开发环境，以便可以在更改时快速测试更改。请记住，您是将一小时分成5个时间段的人。如果某件事需要一个小时，请在日程表上标明。20-30%是我自己的发现。你的可能和我的不一样。评估你自己的（修复一个紧迫的错误需要多长时间？你知道代码库的哪一部分是最麻烦的程序吗？随机找一段程序，看看你是否知道它做了什么。如果不知道，你需要改变它。很多时间）。分类什么时候做什么和应该做什么。（那些知道完成事情(GTD)的人会认为这是一个重要的生产力提示。）***，最近我越来越喜欢把事情写在纸上。与感觉、打印的说明、纸上的优先任务列表或一段代码相反，它通常会成为花费大量时间盯着屏幕的平衡。我希望这些方法对你有用。如果你有其他更好的技巧，请在评论中告诉我。谢谢。英文原文：EngineeringManagersShouldCode30%ofTheirTime翻译链接：http://www.vaikan.com/engineering-managers-should-code-30-of-their-time/
