Coding

原始链接 https://blog.senko.net/code-was-never-the-hard-part-is-an-insult-to-all-programmers 附: HackerNews 摘要的AI 总结 https://t.me/hacker_news_zh/23810 软件开发行业正处于剧烈的变革之中。随着 AI 革 命的推进，编程工作面临转型。许多人近期常说 “大语言模型（LLM）擅长编程，但软件开发从来 就不是难点”或“编程很容易，搞清楚要编写什么 才是难点”。作者 Senko Rašić 认为这种观点是对 所有程序员的极大侮辱。 如果编程很容易 如果编程真的很容易，为什么程序员多年来一直 供不应求且薪资高昂？为什么在 AI 出现之前，程 序员就面临巨大的压力、过度劳累和职业倦怠？ 如果初学者就能轻松完成工作，为什么公司还要 通过复杂的算法面试来寻找顶尖开发者？ 作者通过一系列反问来驳斥编程容易论： • 为什么会有《代码整洁之道》和《程序员修炼 之道》这类厚重的专业书籍？ • 为什么计算机科学需要专门的学位或高强度 的训练营？ • 如果编程简单，为什么会出现像约翰·卡马克 或法布里斯·贝拉这样被公认为天才的人物？ • 如果编程简单，为什么人们会对 AI 抓取自己 的代码感到愤怒？ • 如果编程简单，为什么现在的软件依然充满 了漏洞（Bug）？ 关于“弄清楚建什么才是难点”的质疑 针对“确定产品需求才是最难的部分”这一说法， 作者提出了以下质疑： • 如果决定建什么是难点，为什么产品经理的 薪水通常没有开发人员高？ • 为什么市场研究人员、可用性专家和客户成 功经理在软件公司中不被视为明星员工？ • 如果寻找需求更难，为什么程序员在销售人 员为了签单而随意承诺新功能时会感到沮丧？ • 如果实现过程很简单，为什么大家不直接构 建十个版本来测试哪一个更受欢迎？ 关于程序员角色的误区 另一种陈词滥调是“软件开发的大部分工作是与利 益相关者沟通”。作者指出，现实中很少有程序员 愿意直接与客户打交道。有些开发者标榜自己是 “解决客户问题的人”，但他们转身就开始讨论单 子（Monad）、内存安全等技术细节，而对客户需 求的理解仅停留在虚构的用户画像上。 作者认为，理解用户和解决问题对项目成功至关 重要，但编写高质量代码同样是一门需要技能、 耐心和经验的工艺。这两者并不对立，优秀的开 发者应该努力兼顾对系统的深度理解和对构建目 的的深度认知。 ...

简介 这是我看TJ的一个视频，不能说有感而发吧，但确实引起了我的一些共鸣，时间有限在这里做些简单的记录和总结，后续有时间再更系统地写自己的感想吧。转载请注明出处。 观点提取 其实大家想问的是：我是否仍然能够通过学习编码时所学到的技能获得报酬 软件不仅仅是编码 编程本身不仅仅是编码 人工智能将能够完成初级工程师目前面临的编码任务，人工智能将能够比那些初级工程师更快、更便宜地执行这些任务 人们不会为代码付费，他们肯定不会付费只是为了观看你的代码，除非你是一个 twitch 流媒体:) 他们支付的是要解决的问题，当你编码时，你不会因为该代码而获得报酬，你会得到报酬来解决别人的实际问题或感知到的问题 你获得报酬的原因是因为你为某人解决的问题（这里后续展开说说，技术/业务间的关系），而这个关系足够有价值，让他们足以放弃他们"心爱的现金"，这可以归结为软件 能够提供比以前更快、更便宜或更可靠的东西。 软件是那些直接在计算机中输入的编码任务的超级集合，因为你需要的不仅仅是好的算法或好的类型系统 你需要理解客户需求需求并在情况发生变化时更新它们，你甚至可能会要出来与客户或利益相关者交谈，所以你要练习沟通技巧。 沟通也包括很多非技术方面，有时你需要向非技术人员传达技术概念 需要能够对您专业领域内的人员说不 项目无法正确完成所有事情 对想做但是成本过高的事情说不 它的价值是什么 软件和制作软件有社交方面的因素，比如倾听反馈和提供建设性反馈，有指导和被指导，有耐心、善意和尊重，所有这些都创建了通常看起来像团队的团队，更有效地创建软件，询问和理解诸如我们如何在这家公司赚钱之类的问题 我曾经工作过的最好的软件开发人员在所有这些方面都很出色，包括编码。他们肯定很擅长编写代码，但他们理解 这些技能中的每一项都帮助我学会更好地完成另一项，只要我们有工作，所有这些技能仍然有用 编程本身不仅仅是编码。两类程序员，一类是解决方案复制者，一类是问题解决者 解决方案复制者不仅仅是使用复制粘贴解决方案，而是使用复制粘贴解决方案来解决复制粘贴问题，而无需检查和确认（这里他举了个非程序员的例子来进一步澄清这两种类型的区别） 解决方案复制者对事情如何运作不感兴趣，他们只是一个一个接需求。他们不知道不同的库、语言和工具可以解决他们的问题的方式，或者可能无法解决他们的问题，他们只是复制粘贴StackOverflow上问题中的第一个解决方案，或者现在可能是他们最喜欢的 llm，直到CI变绿为止，而不考虑他们当前所处环境 这不仅仅限于我们一直在谈论的技术问题，可能是他们对如何赚钱或者他们的客户想要什么，也许他们从未考虑过「我们自己组织的结构是否可以帮助我们实现我们打算做的目标和愿望」 相比之下，我们有问题解决者，这些都是好奇的人 他们试图通过理解来解决问题，我认为即使我们不再编写一行代码，这些技能仍然有用 我认为人们低估了他们可以通过软件开发再次学习的技能。 我的观点是，即使你已经编写代码很长时间了，也有可能不学习这些，也不练习这些。例如 例如，我认为逻辑思维是我们在做软件时可以练习的东西 开发中，我们可以练习将大问题分解为更小的问题 我们可以致力于识别迭代并为客户解决问题，他们实际上愿意为您付费，以便可以更好地进行领域分析，正确理解问题集可能的解决方案，然后如何实施一些业务逻辑或流程来解决问题 可以致力于预测这些流程的边缘情况或故障模式 学习如何管理/解决工程中的权衡点 模式识别 这对我们都很有用。在我看来，这些技能中的每一项至少都像你可以训练并变得更好的肌肉，你可以使用软件开发作为进行训练的工具，只要我们有能力，所有这些技能都将再次有用 这些在工作中的软技能，其实与我在软件部分提到的软技能一样（然后举了两个Neovim相关的例子） 您可以用任何您想要的技术替换 neovim， react、rust、htmx、Excel等等，模式和想法是相同的，我的最终观点是您可以 选择你将如何解决问题以及你从实际解决问题中获得的收获，从单纯的复制粘贴转向"Problem Solver" 在实际的例子中，你可以尝试为自己构建一些东西来做到这一点解决你遇到的实际问题。如果其他人已经构建了它也没关系，重点是你要为自己构建它，看看你是否可以解决这个问题 为自己构建一些东西的时候，你就是自己有效反馈，让你知道你是否解决了问题。如果你没有解决，那没关系，你可以重复。失败是可以的，这是我们学习的一部分，重要的是我们利用我们的粗糙和坚韧再次尝试 但要明确的是，我并不是说解决方案复印机是坏人，或者我不喜欢他们，相反，我试图传达这样的信息：如果我开发的所有技能都围绕着重复现有解决方案（拾人牙慧），我会更担心。对我来说，现有的解决方案似乎是一个更有可能通过人工智能以某种方式实现自动化的领域 对我来说有这样的建议，比如保持好奇心，注意努力工作，不要害怕失败。那些从来没有真正让我误入歧途。在我看来以这种方式思考是正确的，无论人工智能如何快速和彻底地扩展到其他软件领域 我不知道未来会是什么样子我 我只是一个普通凡人。但我确实认为，即使不考虑我在整个视频中提出的所有论点，如果你当前的假设是数十亿行新代码将会产生，那么重要的是真正理解有关代码的一些事情，不是所有的事情，不是每种语言，不是每种框架，不是每种类型系统，而是关于软件本身的一些事情 在我看来，与您可能拥有的任何其他可能的技能相比，这似乎是一项更有益的技能 我希望这可以鼓励你在你的软件中努力学习和努力工作，并且也有一些信心，即使我们在编写代码这件事情本身上完全被淘汰，我们正在学习的很多内容都非常有用，并可以转移到其他领域 附录Appendices 原视频