我如何仍然以技术负责人的身份编写代码？

之前我曾建议有效的技术主管在代码编写上花费至少 30％的理想时间。 我在参加的技术主管培训课程中听到的一个常见问题是：

当我承担所有其他责任时，我在哪里找到时间编码？

我知道许多技术负责人都在努力寻找合适数量的代码，并且还在努力知道要执行什么样的任务。 以下是对我和其他人有所帮助的一些有用建议：

避免处理关键路径项目

尽管甘特图在IT中起了坏名声，但它们确实提供了有用的可视化模型来描绘关键链和查看关键路径 。 技术负责人通常会发现自己被打扰了，并且找到固定的编码时间块是不寻常的。 作为指导，我建议技术负责人不要专注于关键路径任务，因为它们通常会阻碍这些任务的进度。

如果关键路径项目仅需要技术主管才能拥有的知识或经验，与另一位开发人员合作完成任务就很有用，这样当技术主管履行职责时，进度就可以继续。

学习委托

委派是技术主管必须开发的技能，也是开发人员很少有机会构建的技能。 情境领导模型清楚地说明了何时授权。 有效的委派取决于个人的技能和动力。 该模型解释了四种模式： 告诉 ， 销售 ， 参与 ， 委托 ，以尽可能多地委托为最终目标。

只有当领导者相信某人具有完成任务的足够技能和动力时，才可以委派任务。

许多技术负责人面临的一个共同挑战是，相信他们以外的人编写的代码足以完成一项适当的任务。

松散配对程序

我不是全职结对编程的忠实拥护者。 但是，很难在全职和什么都没有之间找到合适的平衡。 一个好的安排是与某人一起研究特定问题的方法或设计，然后进行定期检查（或简短的成对编程会议），以查看编写代码时出现了哪些新信息或挑战。

这种设计和代码上的“协同工作”风格对于技术负责人非常有效，他们会发现自己经常被打扰。

避免不必要的会议或会议召开得不好

程序员参加毫无目的或没有结果的会议没有比这更糟的了。 这些令人沮丧，因为花费在会议上的时间很浪费。 了解如何召开有效的会议 ，以避免无效会议的挫败感。

使用“ 有效会议的5 P ”模式：

• 目的 –会议目的明确吗？ 确保每次会议都有一个明确的目的。 示例包括：分发信息，收集信息，集体讨论解决方案以及寻求协议或共识。
• 产品 –当您知道会议的结果时，可以缩短会议时间。 定义会议的成功标准（将与目的相关），以使会议保持专注并保持正轨。
• 参与者 –取消/重新安排会议比与错误的人举行会议要好。 Esther Derby的推文对此进行了很好的总结。
  
• 可能的问题 –在会议期间提出或解决的威胁或威胁有哪些问题？
• 流程 –每次会议都应明确会议的召开方式，人们如何参加会议以及可能需要做什么的特殊规则。 会议主持人应首先阐明会议的目的，以重新设置人们的期望。

学会说不

领导的技巧是说不，而不是说。 说是很容易。 —托尼·布莱尔

作为技术负责人，您将承受始终承担比可能承担更多的压力。 您同意的活动越多，技术负责人编写代码的时间就越少。 如果编码对您确实很重要（应该如此），那么您需要了解什么是真正重要的，以及其他人或非技术人员可以完成的事情。

屏蔽编码时间

我知道有些技术主管会定期在日记中设置日历时间，以确保他们的编码时间不受干扰。 开发人员知道中断是如何打乱思路的，与开发人员相比，技术负责人会发现自己受到的干扰更大。

结论

技术负责人花时间编写代码很重要，但其他职责需要时间。 保持平衡是很棘手的，但是上述技术可以帮助您减少代码。 如果您有其他建议，请发表评论。

翻译自: https://www.javacodegeeks.com/2014/11/how-do-i-still-write-code-as-a-tech-lead.html