管理者应该编码，但不是在工作时

管理者应该编码吗?这个问题似乎没有一个明确的答案。这场辩论有支持者也有反对者，每一方都有自己的论点。我最近在工作中编写了一个副业项目，这让我重新评估了我在这个问题上的立场。经历了这些之后，我可以说，我的立场已经从管理者不应该编码变成了管理者应该编码，但不能在工作中编码。

我管理工程团队已经有几年了，我转型时做的一件事就是停止编码。主要原因是，尝试在你的团队中编写代码会让你成为团队中其他人的阻碍，一天中没有足够的时间来参加所有的会议和单独的会议，也没有时间来编写代码，而且从编码中退一步来展示对团队的信任是很重要的。

另一方面，随着时间的推移，你不再以经理的身份编码，你就会与你的团队脱节。你慢慢开始忘记构建系统和产品的真实过程。你会发现很难遵循团队的一些技术决策。从长远来看，这可能会导致最坏的情况，即由于缺乏可信度而失去团队的尊重。

这两种选择造成的难题导致了工程领导者的永久冲突。其核心是管理者和创造者之间的一场拉锯战。经理的日程是由连续的上下文切换组成的，从一个会议到另一个会议。另一方面，创造者时间表需要大量连续的专注时间来创造。作为一名经理，你的工作要求你按照经理的时间表工作，但为了编码，你需要一个创造者的时间表。

最近，我为我的团队重构了一个会议调度程序，并在我们的系统上部署了周工作安排工具。这是我在周工作安排期间开始做的一个“业余项目”，之后一直在做。它现在已被团队部署并使用。

在这次经历中，我发现了一些事情。首先，我真的很想念编码以及通过构建东西、定位和修复难以捉摸的bug而获得的成就感和成功。我还意识到，我与团队日常工作的联系比我最初想象的要少得多:我们开发环境设置的细节，以及我们如何打包和部署我们的服务。总而言之，似乎我应该更经常地编码，这样我才能更好地与我的团队产生共鸣。

然而，我注意到从事这个项目对我的管理职责有影响。在一对一的情况下，我无法完全集中精力听手头的话题。在我的内心深处，我在思考我的代码:我可以做什么优化，如何消除当前令人沮丧的bug等等。在最糟糕的情况下，我“劫持”了一对一到结对程序的一部分。

虽然我的团队在这方面很出色，但我不认为这是一个可持续的模式。我发现从我的代码切换到完全专注于会议是非常困难的:管理者和程序员的日程总是会出现问题。但总的来说，我很享受这种体验，并且不认为完全停下来写代码是很好的。
最后，我将继续编码，但不是在工作中。我需要在经理和编码之间有一个清晰的划分，这样我就可以完全专注于我的团队和会议。