跳转到主要内容

过去人们普遍认为,程序员的职业生涯是有期限的,过渡到管理是唯一的出路,而过渡意味着编码的终结。 这种老生常谈正在改变。

软件行业的许多领导者都出自在职开发人员的行列。他们经常希望扩展到管理领域,因为他们对技术的掌握给了他们信心,但他们不想放弃坦率地给他们带来成就感的实践。

进入编码领导者。


与技术同行,并以同等的能力在商业和技术世界中行走。

通过与编码实践保持同步,这些领导者可以保持对项目运作的洞察力,保持行业发展的领先地位,并且可以了解哪些变化最有利于组织。

这种趋势可能有助于解决软件行业中最棘手的问题之一:开发人员认为他们背负着糟糕的管理者的感觉。

误区:程序员不可能是好的领导者


编码员的日常工作通常是详细的,可以确定的是逐行的,而且它可能倾向于考虑树木而不是森林。

对于工程师来说,长期存在的危险在于沉迷于构建事物,而忽视了他们所做工作的商业价值。我认为这是桂河大桥的失误,角色的临时技术任务(建造桥梁)使更高的目标(克服帝国占领)黯然失色。

但是随着开发人员在其角色中的成长,他们的愿景包括更多的系统和流程,以及对各个元素的理解。当熟练的开发人员变得真正有经验时,特别是当他们对正在开发的特定系统的了解变得广泛时,他们能够深入到高价值领域,协助进行更改并保持高层次的观点。除此之外,对事物的商业方面的欣赏有助于人才的有效结合。

这里需要编码人员改变思维方式,以实现真正的优先级平衡。虽然在职开发人员可能倾向于将除实际编码之外的任何事情视为简单的中断,但成功的编码领导者可以牢记业务和技术需求的重要性——类似于工作/生活的平衡,两者都具有同等的关注度。

编码领导者知道如何保持一个包含树木和森林的广阔视野,如何在它们之间转换,特别是如何让两者相互通知,以便洞察力在它们之间流动。

当然,这包括在业务中指导人类的工作。

误区:程序员不善待人


这是一个陈腐的概念。这也有点真实。

机器是合乎逻辑的,并且可以通过以正确的方式告诉它们来强制执行您想要的操作。人们不是。领导人们在本质上有所不同。随着程序员从做事发展到领导其他人做事,再到领导人们领导人们做事,这种区别被放大了。

有些人只是对人有诀窍,如何从他们身上引出他们的需求、恐惧和欲望;如何感知人格冲突发生在哪里;如何查看它们可以在哪里生长;以及如何有效地与这些力量互动以帮助他们和企业取得成功。

对于我们其他人来说,这些都是后天习得的,有时是来之不易的技能。编码员也不例外。通过承认人际互动的重要性,编码领导者承诺获得洞察力和技能,就像他们在编写 for 循环或功能组件时所做的那样令人生畏和陌生。公司的内部运作与互联网一样令人震惊。

美妙之处在于,编码员在领导其他编码员和技术人员方面具有巨大优势。

编码领导者是“我们中的一员”


每个程序员都会认识到这种情况:项目经理漫步并根据他们的甘特图做出荒谬的预测。或者更令人畏惧的是,开始滥用流行语。以有效的方式将业务需求传达给建设者是一门特殊的艺术。成为两者之间的有效桥梁更为珍贵。

将硅片合规化的实际经验是无可替代的。这不仅转化为对正在完成的技术工作的更深层次的同情,而且转化为对该行业赋予人们的特殊乐趣和从人们身上收取的费用。

知道在战壕里是什么感觉,保持活力是很有价值的。在提高技术管理的感知和实际绩效方面,让自己置身于工作编码人员的鞋子中的能力无疑是一大难题。

在研究和思考编码与管理的问题时,我碰巧给机械师带来了一辆汽车。这家商店规模很大,但我看到店主走到一辆车前,爬到车下帮助诊断问题。具有领导者愿意和能力跳入困境的工程师有一定的尊重。

这种尊重和喜爱转化为软件世界,领导者被视为“我们中的一员”。

领导者应该继续编码吗?


MongoDB 的 CTO Mark Porter 在写下自己作为编码员和经理的经历时说:“CTO 有很多种类型。领导公司第一个产品开发的小公司的 CTO 绝对应该编码。专注于大公司对外活动的 CTO 不应该这样做。”

这是一个现实的承认,当然有些角色要求填补它的人放弃动手编码,但世界上也有热爱编码,想要继续参与其中的人的地方,并且也成长为领导。

如今,即使是具有深厚实践技术知识的杰出领导者也不难找到。例如,AWS 的 Werner Vogels 和 Brave 的 Brendan Eich 给出了了解和关心动手开发人员所关心的各种细节的所有迹象。

在技​​术工具领域,这种专业知识更有价值。编码领导者不仅能够更好地与内部开发人员建立联系,而且还能够与客户建立联系。

编码领导者表明,程序员就像古典音乐家,而不是足球运动员或战斗机飞行员。一位古典音乐家可能会成长为一名指挥家,他会保持他们的乐器实力以改进他们的工作。

在考虑职业道路这一重大问题时,必须选择一条非此即彼的道路来实践编码员或 IT 领导者的想法变得不那么具体了。它也许可以被看作是一个频谱,而不是一个析取。一方面是纯粹的商业领袖,另一方面是纯粹的工程师。大多数 CIO、CTO 或其他技术领导者将融合这两个方面的一些方面,而编码领导者则更多地处于中间位置。

至于问题,我应该成为经理还是程序员?也许答案是:两者兼而有之。

本文:https://cioctocdo.com/coding-leaders-forge-new-path-it-career-advanceme…