“代码从来都不是最难的部分”是在侮辱所有程序员

“代码从来都不是最难的部分”的含义

• 许多人将其理解为：一旦你有了经验，写代码并不是瓶颈；真正困难的是决定做什么、如何设计，以及如何将其融入混乱的组织中。
• 也有人认为这种说法具有误导性或带有侮辱意味，因为它听起来像是在说“编码很简单”，并抹去了真实存在的技术难度，尤其是在非平凡领域中。

编码难吗？

• 一些人认为，基础编码对很多人来说本质上就是困难的（计算机科学肄业率、fizzbuzz 失败、需要多年练习）。
• 另一些人则说，与需求、架构、沟通和政治相比，实现代码的行为往往是整个工作的最容易部分。
• 人们常常区分“让东西跑起来”与编写高性能、正确、可维护、可演进的代码；后者仍然被视为困难的。

编码 vs. 编程 / 工程

• 一个反复出现的主题是：编码 = 输入指令；编程/工程 = 解决问题、设计、建模领域、集成系统，以及运行和演进这些系统。
• 许多人说，优秀工程师不可避免地要戴上“看不见的帽子”：需求梳理、架构、性能、安全、合规、运维。

AI/LLMs 及其影响

• 有人声称，LLMs 已经把日常编码的大部分工作变成了低技能的“line cook/burger flipping”式劳动；真正的价值上移到设计、编排和规格定义。
• 也有人表示，LLMs 生成的代码更粗糙、bug 更多或更不安全，尤其是在复杂系统（分布式、受监管、性能关键）中，这反而增加了审查和维护负担。
• 共同的看法是：LLMs 有助于处理样板代码和“打字”，但无法取代深度理解、长期维护或正确的高层决策。

产品、需求与组织

• 许多人表示，真正的瓶颈是需求不清、优先级不断变化，以及跨职能对齐；“没有会议的编码日”非常稀少，也因此格外珍贵。
• 关于谁应负责用户理解，存在分歧：一些人认为工程师必须尽早参与；另一些人则认为产品/PM 应该为工程师挡住干扰并负责调研。

质量、维护与监管

• 维护和调试被一再提及为最困难、最耗时的部分；许多现有代码“连基础审计都过不了”。
• 在受监管或安全关键领域，流程和文档可能比代码本身还要庞大，但代码仍必须正确，而且也很难安全地修改。

劳动、地位与身份

• 一些人认为，“代码从来都不是最难的部分”是在自动化焦虑面前的一种心理安慰叙事。
• 另一些人指出，高薪反映的是稀缺性和杠杆，而不仅仅是难度；而且许多非编码技能（产品、管理）同样困难，只是它们的价值没有那么显眼。