近日，一名有超过 15 年软件开发经验的软件开发人员在 Hacker News 上提出了一个问题：如何才能成为一个好的技术***?该问题一经提出，在不到一天的时间内就获得了 160 多条回复。关于技术***应该具备的品质和管理技巧，网友们提出了各自的看法和建议，本文择要归纳如下。
如果不能从帮助团队获得满足感，那么就不要成为一名***
技术***要忙于会议、计划、打断、团队沟通、文档等工作，永远无法达到一个人单独工作时所能达到的那种个体生产力。
技术***的工作不再是让自己成为***的编码人员，而是要尽可能地让其他人成为***的编码人员。工作分配也要以一种有利于团队和个人成长的方式进行。要负责为团队成员清楚障碍，让他们的工作进入正轨。
技术***的满足感来自新人的培养和成长。
将自己视为其他开发人员的导师
即使已经知道了答案，有时候也需要让团队自行决策。许多时候，正确的答案并不唯一。技术***的工作不是选择正确的答案，而是确保团队不选择错误的答案。允许团队作为一个整体自行决策有利于保持高涨的士气，让每名成员都更有自豪感和主人翁精神。
在有关技术问题上，团队信任并依赖你的建议/观点。作为技术***要了解团队所开发的应用，了解该应用所涉及的领域，了解功能背后的技术，并编写详细的技术文档。
有时候，技术***同时也是***工程师。这时，他所能为团队做的最有价值的事情是在开始和结束时为团队成员提供帮助。
有时候，技术***还是架构师。当解释系统或代码的行为时，他需要能够快速改变高度。当同开发人员调试问题时，他要能够深入技术细节;而当向 CEO 解释计划或成本估算时，他要能够在一个更高的层次上谈论系统。
随时准备好回答团队成员的问题
但当你有问题要问他们时要首先询问他们是否方便。这很难做到，因为作为一名技术***，你有许多工作要做。但是，为了可以有更多的时间回答他人的问题及为其他人提供支持，可以将复杂的任务委派给团队中更有经验的成员。
很多时候，团队成员的问题本可以在空闲或闲聊的时候提出。为此，引入可异步使用的生产力工具是一种更好的方式，比如，对于一些不太紧急的问题，可以借助 Trello 卡片或 GitHub 问题跟踪器提出。不过，不管采用什么样的沟通机制，关键是要获得其他团队成员的支持，让他们在工作无法进行或完成的时候，可以很舒服地打断你。
为了了解团队成员，技术***要定期主动同团队成员进行一对一的沟通。每名开发人员都是不同的，通过沟通可以了解到这种不同。
减少具体的编码工作，但仍然要编码
即使不做很多具体的编码工作，也仍然需要监控和接受所有的 pull request，并利用这个过程，帮助初级开发者修改代码。这是必须的，如果不编码，那么开发人员会质疑你的判断，不容易接受你的建议。
但是，作为技术***，你的首要任务是确保团队成员的生产力，而不是自己的生产力。你要为整个团队的输出负责，如果那意味着零编码，那么就不要编码了。同时，这也意味着，即使代价是停下自己的工作，也要帮助处于困境中的团队成员。
要谦逊
要相信，你的团队所具备的能力和理解力都要超过你。
要承认，关于某个主题或组件，有人懂得比你多。成为一名优秀的***，并不需要事事都懂得比别人多。
如果团队成员都将你视为权威，那么他们会害怕自己做决策。在这种情况下，你就成了障碍。
要诚实
当你知道答案的时候，就说出来，即使那意味着某些人要重做大量的工作。如果你不知道答案，也要说出来，不能不懂装懂。你获得了当前的职位，就说明你有资格，你永远不需要向其他人证明你的能力。
除了上述这些讨论比较多的观点外，还有一些其它的观点，比如，把令人愉快的任务分给别人，把令人讨厌的任务留给自己;公开表扬，私底下批评;让每个团队成员都清楚地知道你对他们的期望;及时反馈和表扬;与非技术管理人员建立稳固的关系等等。还有一些行为是技术***应该避免的，比如，不要抱怨代码库有多糟糕;不要说“我们要重写 XYZ”，技术债务要逐步解决;不要轻易提议使用可选的平台和框架。不过，需要注意的是，不同的组织有不同的企业文化，对技术和技术***有不同的看法和预期，技术***要以此为出发点考虑问题。
