我的合同期是12个月(我住在一个国家,对于新的开发人员来说,这并不常见),直到几周前,我公司的管理层给了我一份报价和加薪,让我成为他们的长期雇员。我喜欢保持我的简历始终是最新的(特别是考虑到COVID),所以我在网上搜索了一下关于在简历上列出它的问题。
我发现的建议是,我一般应该列出促使雇用的成就。这很合理。
问题是,这些成就总是在紧张的客户期限内完成,坦率地说,我是通过决定在有针对性的情况下工程可以不那么出色而做到的(管理层也同意)。
我是一个由6名开发人员组成的团队中相对初级的开发人员。然而,我已经迅速成为管理层最信任的开发人员之一,当我说要交付时,我就会交付,并让他们了解达到目的的相对权衡。在我在这里的短暂时间里,我总是能够在我说我能交付的时候交付东西。
我有过几个这样的案例,但这是我在获得永久工作机会之前做的一个。我们的一个产品是一个批处理API,每天被一个客户调用一次。它不需要返回任何东西,除了通过电子邮件返回失败的条目的CSV。他们希望增加一个新的功能,销售人员在合同中同意在月底前为他们完成这个功能。由于各种原因,该功能请求直到本月最后一周的周一才下达给我们。
高级开发人员告诉经理,开发工作无法正常进行,并告诉客户无法完成。我不会在冲刺计划会议上反驳高级开发人员,但也许很明显,我不同意高级人员的意见。比如说,不是不同意,而是存在一个有某些交换条件的选择。其他开发人员也相当被动,所以其他人也没有反驳他。 经理对此很不高兴,因为客户已经对我们承诺不提供服务而感到愤怒。经理于是在会后把我叫到他的办公室,问我是否看到了一个替代方案。我告诉他,我可以想办法,但可能会使API的处理时间增加一倍(会增加4分钟),因为我没有专门的SQL技能。经理同意了,显然,客户甚至没有注意到。
我不确定错过最后期限的后果是什么,但它们足够陡峭,以至于我们这个有1000人的公司的首席执行官给我发了一封感谢信,感谢我把它送出去。
另一个案例没有引起那么多的注意,但我们需要在数据库上运行一个程序。正确的做法是在我们使用的大型Java系统中编写一个适当的批处理程序,通过所有常规的QA流程发送,并在两周后让它跳出来。我给经理提供了一个Python脚本,这个脚本需要手动运行,而且效率低得吓人(必须通宵运行),但如果每个月触发一次,就可以在永久修复之前将问题控制住。这是一个生产问题,所以他同意将其作为一个权宜之计。这基本上只是一个廉价的for循环,检查某类错误数据的行并重新格式化。
有什么办法可以在我的简历上列出这些类型的东西,而不至于让我看起来像一个破坏高级开发人员的黑客程序员?我承认我的解决方案在技术上并不健全,但它们对当时的业务需求来说是健全的,而且在大多数情况下,效率低下的权衡基本上是不重要的。
你找到了几个有效(而不是高效)的方法来解决问题,而没有过度的工程化,而且"做的比完美的好"。
找到一个刚刚好的解决方案是工程师的重要能力,否则你会花很多时间去优化不值得优化的东西。 如果一个东西不经常使用,往往就不值得去优化它。有一个很好的XKCD-Comic的表格,告诉你应该在某个东西上投入多少时间。
一个解决方案只有在它被使用(或可以被使用)时才有价值,所以通过黑客,你让客户继续工作,直到你有一个解决方案。
没有理由告诉别人你与你的上司意见相左。你可以选择像 "能够在时间压力下提出有效的解决方案 "这样的内容。
我承认我的解决方案在技术上并不完善,但它们是 但它们对当时的业务需求来说是合理的,而且低效率的交易 在大多数情况下都是无关紧要的。
你的工作只有一个:在规定的时间内找到一个能解决工作的解决方案"。而这正是你所做的。
我感觉这里只有管理层一直在给出答案,因为在坚持不合理的最后期限时,除了表扬,什么都没有。
这里还有另一种观点。你不要小看当管理层偷工减料,无视高级开发人员的意见时,你在开发团队内部燃起的社会骚动。有一句话大致是这样说的。
只要有一个人在不断地灭火,管理层就不会停止玩火柴。
如果你一次/两次因为被逼无奈而走上黑客之路是一回事,但如果越来越成为常态,那就完全不同了。而且从你的描述中,我觉得管理层对利用你挖角的做法已经相当习惯了。你应该认真考虑向你的管理层和高级开发人员提出这个问题,以维持健康的工作环境。一个公司是开发和管理之间的平衡,而不是简单的自上而下的结构。"不 "这个词的存在是有原因的,你应该练习使用它。
然而,这更多的还是管理层的问题,而不是你的问题。因此,你没有理由在简历中莫名其妙地提到这一点。所以,我会顺着。
能在最后期限内完成任务
俗话说:"完美是好的敌人"--为了满足业务需求而做出技术上的妥协,这几乎是理所当然的。优秀的开发者/程序员/工程师是那些能够确定可接受的*折衷的人。
在你的API例子中,客户显然更愿意接受4分钟的处理延迟,以换取能够工作并按时交付的东西。
理想情况下,在做出这些妥协时,你应该寻求将技术债务降到最低--但这都是经验的一部分,知道你在什么地方可以节省时间,什么时候你需要确保某些事情做得正确,以便从长远来看节省更多时间。
我的基本问题是,有没有一种方法可以在我的简历上列出这些类型的事情,而不会让我看起来像一个破坏高级开发人员的黑客程序员?
当涉及到你的简历时,没有必要深入了解你的解决方案的具体内容--你可以简单地说,你在时间紧迫的项目上有按期交付的良好记录,并提及实例,而不提及实际执行的细节。
你所做的不是 "黑客",而是 "寻找解决方案"。
我从事开发和咨询工作已经有20年了,这种技能是雇主所寻找的。不要在你的简历中漏掉它,而要准确地强调它。你试图找到解决方案,即使这意味着走不寻常的道路。
不要写你背着高级开发人员做这些事,而是写你在被要求提供解决方案时都会这样做,即使更有经验的人不同意/说它不可能。
有一句话据说来自阿尔伯特-爱因斯坦,正好描述了你的情况。
每个人都知道这是不可能的,直到一个不知道的傻瓜出现并做到这一点。
我和很多开发人员一起工作,我知道这其中的每一个方面。
我和一个开发人员一起工作,他是stackoverflow网站上排名前1%的JavaScript专家。他是个天才,我真的很佩服他写的每一行代码。但他经常不完成他的项目。他宁可不完成某件事,也不愿意在对代码的美感不满意的情况下完成它。
我曾与那些效率极高的开发人员共事,但也因此走了很多捷径,使得解决方案几乎无法维护(硬编码路径、神奇数字等)。
我总是喜欢 "完成",而不是 "美丽",最后我的客户也是如此。他们宁可在最后期限到来时拥有"东西",而不是"什么都没有,但再过一段时间就会变漂亮"。
只有一件事:变通/捷径/"黑客"需要可理解、可记录和可维护,那么就没有什么可以反对像你这样的解决方案。
你描述的是技术性债务,而技术性债务并不总是坏事。债务的类比延伸到公司为什么会承担金融债务,有很多合理的理由。关键是它是有意的,并且有一个现实的计划来偿还它。马丁-福勒对此有大量的文章,特别是他所说的技术性债务象限。
听起来你对技术性债务做出了一个谨慎的决定。认识到技术性债务的审慎之处,并知道如何管理技术性债务,是极为宝贵的技能。
我把 "你的简历适合放在这个故事里吗?"这个问题放在一边。也许简历中没有空间去描述这样的细节,但假设这是面试中可能会出现的事情,你要考虑如何以最好的方式去呈现。无论如何,即使没有人再谈论这件事,也值得你思考一下对自己职业发展的影响。现在,我想提出的一个意见是中肯的,别人都没有提到。
**你仍然有这份工作。
你正在研究如何最好地呈现这个故事,但也有特权能够改变这个故事。
所以,你做出了一个判断,并承担了风险。正因为如此,你成功地在截止日期前实现了完全可观察的功能,满足了客户的要求,并给你的经理留下了深刻的印象。正因为如此,你也交付了一个执行成本高于所需的解决方案,可能损害了代码库的设计,并让你的团队领导感到尴尬。 这是一个合理的判断。其他人已经解释了如何呈现这种情况:你把团队内部的冲突完全排除在故事之外,你明确指出你的解决方案存在的技术问题,你认识到了这些问题,同时也意识到了商业现实,你解释说你做出了一个决定。
但如果你能讲出一个更好的故事,它将包括拿下和清理这笔债务。 这将包括现在截止日期没有迫近,花一点时间复习,也许是为了更好地封装代码,增加一些关键的单元测试。它可能意味着刨去两个额外的4分钟,也许是咨询你当地的SQL专家。这将包括寻找与你的团队其他成员慷慨分享功劳的方法。
如果你不想被人认为是一个动作快、破坏东西的家伙,那么就评估你的决定(包括艰难但非常合理的决定)所造成的技术、业务和人际关系的混乱,并负责清理它们。
你还有工作.。
所以,你创建了一些软件,花了4分钟运行(因为你的代码不是很好)。如果我手工做这个工作需要12个小时,你的软件为我节省了11小时56分钟。如果你写了更好的代码,运行时间为1秒,则为我节省了11小时59分59秒。如果更好的代码在一周后交付,所以我不得不手动做5次工作,多出来的3分59秒永远无法弥补我损失的时间。
或者做得更极端。软件需要在24小时内运行。你的代码很糟糕,所以我们需要一台5000美元的电脑来在24小时内运行它。如果有更好的代码,2000元的电脑就能在24小时内运行。节省了3000美元 如果你花了两周时间让代码更快,那就是整体损失。
在需要的时候能够交付是一件非常非常好的事情。另外,一个非常优秀的开发人员可以把不好的代码写得很好,这样以后就可以很容易地改进。坏的开发者写出的坏代码,要重构成好的形态很麻烦,好的开发者在时间压力下,写出的坏代码很容易改进。
解读爱因斯坦。
软件质量应该尽可能的降低,但不能降低。
我知道有很多开发人员对自己写的代码感到自豪,坚决不同意这个观点。但从商业的角度来看,一旦达到了软件质量目标,进一步提高质量就等于在没有要求你做的事情上花费了额外的工作,也没有得到报酬。绝对质量是根本无法达到的:无论你的软件有多好,总是有改进的空间。
很明显,你不是因为降代码质量而受到表扬。你被表扬的是保持可接受的代码质量,同时也满足了截止日期。你应该在简历中这样表述。
我对你的简历上写什么这个问题没有特别的看法,虽然我倾向于同意那些说这种东西不适合写在简历上的答案。
不过,我想指出的是,如果我和你一起面试,你描述的情况和问题中的一样,会发生什么。
我的第一反应会是:"很好,我喜欢一个能在短期内做必要的事情,同时又能认识到他所做的权衡的人。" 但是,在贵公司的软件项目管理中,也有一个很明显的问题,我想请你找出。
我想听到的答案是,某个非技术团队的人在某一特定的截止日期前向客户承诺了某件事情,而技术团队手中却没有估计到何时能交付。这样做是长期灾难的秘诀。如果你不能识别出这种问题,我会非常谨慎地让你加入我的团队。
此外,一旦发现了问题,就需要有人对其实施长期的修复措施,以确保问题逐渐减少,最好是最终消除。我想问你,你在新的管理岗位上,为实现这一目标做了什么?如果你不能想出一个好的答案,我又会对雇佣你相当谨慎。承担昂贵的短期修复的责任是很好的,但如果你不承担长期修复的责任,消除那些昂贵的短期修复的需要,并从整体上为公司节省时间和金钱,我会认为你只适合做一个初级的角色,直到你学会了这样做。