卓越程序员的起点：渴望与自我提升

2011年1月17日 by Max Kanat-Alexander

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

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

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

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

尽管这很难想象，但当你告诉许多“糟糕”的程序员如何或为什么应该编写更好的代码时，他们的脑海中就会发生这种情况。如果他们不是真心想成为最好的程序员，那么无论你给他们多少教育、纠正他们多少次，或者他们参加多少研讨会，他们都不会变得更好。

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

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

无论你怎么做，底线是人们必须对提升自己感兴趣，才能变得更好。你如何让他们达到这种兴趣水平并不重要，只要他们在你浪费大量时间给他们提供他们一听就会扔掉的教育之前达到那种水平。

-Max

分享点击分享到 Facebook（在新窗口中打开） Facebook 点击分享到 LinkedIn（在新窗口中打开） LinkedIn 点击分享到 Hacker News（在新窗口中打开） Hacker News 点击分享到 Reddit（在新窗口中打开） Reddit 点击分享到 Threads（在新窗口中打开） Threads 点击分享到 X（在新窗口中打开） X

5条评论 留下回复

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代理能够成功生成的输出数量和质量取决于：

模型的质量。
代理的质量。
输入的质量（如提示或其他上下文）。
代理可以独立运行的确定性、客观验证的质量。

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

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

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

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

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

阅读更多2310分享

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

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

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

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

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

阅读更多12940分享

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

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

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

对于许多帖子，你会发现：这条数据根本不会帮助你做任何事。

阅读更多249分享

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

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

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

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

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

阅读更多274分享加载更多