所谓 -10x 工程师,不是能力稍弱,而是通过模糊需求、制造无效讨论、增加构建等待、引入不稳定测试、浪费云资源或阻止低绩效处理,持续消耗整个团队的产能。文章用反讽方式列出这些行为,提醒团队关注系统性负效率:一个人造成的沟通、流程和技术成本,可能抵消许多工程师的产出。
作为 Vets Who Code 的执行董事,我对 300 多名退伍军人和军人配偶进行了网络开发培训,帮助他们为职业生涯的每一步做好准备。高级工程师通常通过展示领导能力(了解您的工作如何适应更大的业务目标、在会议中增加价值、指导同事等)以及将工作与业务优先事项和结果联系起来的意愿来使自己脱颖而出。高级工程职位的候选人应善于识别需要增量改进的领域,并善于利用团队资源来有效管理关键服务中断,以快速减少对客户的不利影响。Build a “brag document” 建立一个“吹牛文档” “吹嘘文档”展示您的专业知识并展示您的成就。It should include: 它应该包括: 已完成的项目:列出您从事过的所有项目,包括所使用的技术、目的,以及最重要的是所取得的成果。Write documentation 编写文档 当您晋升为高级职位时,您需要为初级工程师树立有效沟通和协作的榜样。
比如「第五条 软件是达到目的的手段」,对于程序员来说,编码不是核心,为什么编码才是核心。我的职业生涯前半段是一名软件工程师,为各种小型企业和初创公司工作,后来我进入咨询行业,在许多大型企业工作过。后来,我创办了 Simple Thread 公司,我们的团队从 2 人发展到 25 人。重视工程师的生产力,而不是其他大多数考虑因素 过去 20 年的经历塑造了我对软件的看法,并使我形成了一些信念,我试图将这些信念归纳为一份易于管理的清单,希望对你有所帮助。软件最难的部分是构建正确的东西 我知道这已经是老生常谈了,但大多数软件工程师之所以不相信,是因为他们认为这贬低了他们的工作。设计软件主要是一种倾听活动,我们常常需要兼具软件工程师、心理学家和人类学家的双重身份。每个系统最终都是糟糕的,克服它吧 Bjarne Stroustrup 有一句名言:"只有两种语言:人们抱怨的语言和没人使用的语言"。
开发者生产力的全貌不只是写代码更快,而是工具、组织执行和客户意识共同塑造工程效率。Steve Yegge的经历把这条线串起来:在GeoWorks,他见到极强的调试器、脚本工具和轻量自动化,即使用汇编写操作系统,工程师仍能高效而愉快;在亚马逊,他从技术项目管理学到跨团队交付,理解客户服务工具必须横向连接所有系统,这种压力后来也推动了服务接口和平台化思维;在谷歌,他看到强大工程文化的另一面,工具和流程可能很先进,却也可能离真实客户过远。真正的生产力不是单点技巧,而是让工程师少受摩擦、让系统边界清晰、让团队能围绕客户问题快速协同。优秀开发工具的价值常常在失去后才显现,因为它们改变的是日常判断和反馈速度。一个工程组织若只谈个人能力,不建设调试、发布、服务接口和跨职能协作,就很难持续放大开发者的产出。