成为卓越程序员的第一步:内在驱动力与技术验证

本文探讨程序员成长的核心前提——内在驱动力,并延伸讨论AI编程中客观验证机制的重要性。强调技术决策的即时影响与代码质量对开发效率的关键作用,提供实用洞察。

在开始之前……

我研究软件设计的一个主要目标是,希望我们能够通过简单的教育和一点经验,将“糟糕的程序员”或平庸的程序员转变为优秀或卓越的程序员。我想知道——你必须教给一个人的基本东西是什么,才能让他们成为伟大的程序员?如果有人编程多年却没有进步——你如何帮助他们?他们缺少什么?因此,我写了很多关于这方面的内容,尤其在我最近的一些文章中。

然而,在某人开始成为更好的软件开发者的道路之前,有一件事必须成立:要成为卓越的程序员,你必须首先想要成为卓越的程序员。再多的培训也无法将不想卓越的人变成卓越的程序员。

如果你是一个对软件开发充满热情的人——或者甚至只是一个喜欢做好本职工作的人——可能很难理解那些根本不想进步的人的观点。要完全理解这一点,可以想象自己尝试学习某个你个人没有欲望擅长的领域。

例如,虽然我钦佩运动员,喜欢踢足球,有时也喜欢观看体育比赛,但我从未有过成为伟大运动员的欲望。再多的阅读或教育也无法让我成为伟大的运动员,因为我根本不想成为运动员。我甚至一开始就不会去读那些书。如果你强迫我参加一些课程或研讨会,信息一进入我的脑海就会消失,因为我根本没有欲望了解这些数据。即使我每天以运动为生,我也会想:“唉,我对运动没有热情,所以这些信息对我根本不重要。总有一天我会做其他工作,或者退休后就不必关心了,在此之前我只是为了赚钱而做,总比饿死好。”

尽管这很难想象,但当你告诉许多“糟糕”的程序员如何或为什么应该编写更好的代码时,他们心里就是这样想的。如果他们不真诚地想要成为最好的程序员,那么你给他们多少教育、纠正他们多少次,或者他们参加多少研讨会,他们都不会进步。

那么你该怎么办?公平地说,我可能不是最好的询问对象——如果我要做某事,我觉得我应该尽力做好。也许你能做的最好的事情是鼓励人们遵循那个概念。你可以对他们说类似的话:“如果你反正要做,为什么不做好呢?如果你更熟练,做这件事会不会至少更愉快?如果其他人对你的工作印象深刻,那会是什么感觉?一天结束时回家感觉自己做了一些好事,会不会很好?你的生活会比现在更好吗,哪怕只是一点点?你的生活会变得更糟吗?”

在最坏的情况下,你可以请某人列出“成为伟大程序员”的所有后果,直到他们对此感到一些解脱或开始以不同的方式看待这个想法。你可以问他们类似“如果你是一个伟大的程序员,会发生什么?”的问题,并不断要求更多答案,直到他们感觉更好或开始真正看到卓越的好处。你不必用任何正面或负面的评论回应他们的答案,只需倾听并礼貌地承认他们所说的话。目的是给他们机会自己真正审视可能性,也许自己得出一些新的有趣的结论——不是通过你告诉他们该想什么或不同意他们的答案,而是通过与你交流如果他们变得伟大会发生什么。

无论你怎么做,底线是人们必须对提高自己感兴趣才能进步。你如何让他们达到那种兴趣水平并不重要,只要他们在你浪费大量时间给他们教育之前达到就行,否则他们一听到就会扔掉。

  • Max

评论

Jolie 说: 2011年1月17日下午3:53
哇!这清晰有用。事实上,你可以将其推广到任何工作。很好。

回复
Max Kanat-Alexander 说: 2011年1月17日晚上11:20
谢谢!是的,我同意,它几乎适用于任何卓越的领域。

  • Max

Ahmed 说: 2011年1月17日晚上11:13
Max,这是成为伟大程序员的优秀起点(欲望)。许多程序员有这种欲望,但仍然是平庸的程序员,因为他们不知道道路。我希望你发布一篇关于初学者成为伟大程序员的步骤的文章。我的建议是:个人项目、博客、阅读代码、每年学习新语言/框架…… Ahmed。

回复
Max Kanat-Alexander 说: 2011年1月17日晚上11:23
谢谢Ahmed!确实,许多人想变得伟大但还没有找到方法!我知道的最好道路是我在《为什么程序员很烂》文章中概述的要点。那篇文章有很多信息,所以有些人错过了接近结尾的要点,但那些是文章最重要的部分!
目前的问题是,其中一个要点——理解软件设计的基础——几乎不可能,因为它们从未被编撰!所以这是博客其他内容的主要主题,但更重要的是,它将是我正在写的一本书的主题,这样人们才能真正拥有和理解这些基础,并继续前进。

  • Max

Dale 说: 2011年2月18日下午4:53
我觉得这令人兴奋,希望容易学习!
谢谢你!

回复 取消回复


最新思考

Max Kanat-Alexander
6月27日
我目前认为,AI代理能够成功生成的输出数量和质量取决于:

  1. 模型的质量。
  2. 代理的质量。
  3. 输入的质量(如提示或其他上下文)。
  4. 代理可以独立运行的确定性、客观验证的质量。

我目前认为,除非你是模型开发者,否则最重要的部分是“确定性、客观验证”。

简单来说,如果你告诉AI做某事,它需要某种方式能够自行验证它做对了。在软件中,这通常意味着运行测试、linter等,如果系统做错了就会失败。

这意味着你的测试和验证工具越好,从模型得到的输出就越好。这不只是测试数量的问题。它们必须是好的测试,具有智能断言和良好的错误消息。

这也意味着代理成功涉及如何将任务分解成可以各自通过自动化测试、linter等客观验证的单个部分。

作为说明,输入的质量也很重要,并在我们控制之下。如果我们编写更好的文档和更清晰的代码,代理会做得更好。令人惊讶的是,几乎所有帮助人类编写代码的东西也帮助代理。

阅读更多
2010 分享

Max Kanat-Alexander
6月4日
技术债务有价值的想法大多是个神话。当你做出糟糕的软件工程决策时,它会在几小时、几天或几周内减慢你的速度。那是上限。许多人认为需要数月或数年才能看到在软件设计上偷工减料的影响,但那根本不正确。它几乎立即开始。做正确事的成本通常是几小时,也许一天,而且你几乎总是立即收回那个时间。也就是说,做对通常花的时间与做错花的时间相同。“等等,什么?那怎么可能?我们偷工减料是为了节省时间!”结果几乎总是它根本不会节省你的时间!它使处理变更更加混乱。它使代码审查更长。它在测试中以更混乱的方式失败,需要更长时间调试。它几乎从不节省你的实际时间。

偶尔,你路径上有些“岩石”如此巨大,你根本无法移动。没有人应该花三个月设计一个新工具,只是为了发布一个一次性的、一天的功能。但那是技术债务决策中极小的一部分。

这变得更疯狂,因为如果你在过程中做对一切(你总是重构系统,使其看起来像是设计来做现在做的事),那么一切在整个过程中保持相对容易。但如果你偷工减料,一切变得复合性更难,以至于你生成没人能移动的“岩石”。复杂性不是某种线性事物,你可以后来投入线性时间修复。你绝对可以陷入一种如此糟糕的情况,以至于你公司中没有人有时间或专业知识修复它。

这一切感觉如此无辜:“让我们偷工减料吧,它会帮助我们满足这个截止日期”(一个通常虚构的截止日期,你可以推迟几周而没有任何后果)。“很难弄清楚如何做对,我们能推迟吗?”然后砰,很快你发现自己陷入沼泽,一切都很困难,“我们不知道为什么!”

我最后留给你一件事:当我每天直接编码时,我在这方面完全 uncompromising。我基本上无法看糟糕的代码——我必须重构它,否则我无法工作。不知何故,在我整个职业生涯的那部分,我从未错过一个截止日期。

阅读更多
9342 分享

Max Kanat-Alexander
5月30日
我估计,我每看到或听到一万条坏建议,才收到一条好建议。互联网充满坏建议,因为文明充满坏建议。文明充满坏建议,因为全球的教育大多不教人们思考、研究或确定什么是真的。相反,它教人们记忆和重复事实,其中大多数不重要、不真实或无用。

所以总的来说,我们不应惊讶互联网(尤其是社交媒体)充满不重要、不真实或无用的信息。并非全部那样——我在网上学到了大量非常有用的东西。有大量有价值的内容。我会说,人们对事物的意见,无论是在报纸、博客文章、论坛还是其他什么,很少具有那种价值。

那么要点是什么?嗯,最好有某种方式在开始依赖或向他人重复之前确定某事是否重要或有用的。最简单的工具是说:“它有效吗?”这条数据可靠地帮助你完成某事吗?它100%有效,还是更少?

对于许多帖子,你会发现:这些数据根本无助于你做任何事。

阅读更多
219 分享

Max Kanat-Alexander
5月29日
你对系统做的任何变更在推出时都会收到某个人的负面反馈。这不是因为每个变更有问题,而是因为用户习惯了系统的工作方式,他们不喜欢它改变了。他们可能批评新用户界面,或有某种情感争论为什么新东西“烂”,但通常他们真的只是对任何变更发生感到不安。这不是什么不寻常的事;它存在于几乎所有人类中。人们往往有一定 appetite 愿意在一定时间内经历多少变更,如果你超出那个,他们会不安。

重要的是识别人们的反馈是简单的“变更厌恶”还是对有价值事物的真实反馈。有几种方法可以判断:

  1. 变更厌恶通常持续3到10天。如果你在推出变更后的前3到10天内收到用户反馈,并且同一反馈不是由大量用户提供,值得考虑用户的响应是否只是变更厌恶。
  2. 变更厌恶反馈通常是情感的。它可能是侮辱性的。它可能表达为只是意见(“新菜单的颜色丑”)vs事实(“我测量了,新工具比旧工具慢10倍”)。

管理变更时,你要避免的是创造如此多的变更厌恶,以至于引起反抗。反抗基本上看起来像如此多的人愤怒,他们去找你的管理层并停止你的工作。如有疑问,向更少的人推出更小的变更,以更慢的扩展速度。随着时间的推移,你将学习可以推出多少变更,多快。永远不要做“大爆炸”发布,让所有用户一次体验巨大变更。

现在,所有这些 said,永远不要将所有反馈归因于“变更厌恶”。通常人们确实有合法的反馈。如果许多人提供你相同的事实反馈,你查看它,他们的反馈有道理,你认为修复它会改进产品,那很可能不是变更厌恶。另外,说“这只是变更厌恶”并不意味着你应该完全忽略反馈。你至少应该承认它,让人们知道他们被听到了。它确实意味着你不应该与那个人争论或尝试理性对待,因为他们有情感反应,你试图用“逻辑”说服他们无助于任何人。如果你认为是变更厌恶,你承认他们,他们只是继续与你争吵,有时你应该忽略他们并继续做你的工作。如果他们3天后带着更合理的论点回来,那么你知道不只是变更厌恶,而且他们可能那时更有帮助。

阅读更多
234 分享

加载更多

© 2025 版权所有。由 The Fox 提供支持。 管理同意 联系 关于 书:理解软件 书:代码简洁性 转到顶部

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计