821 points
• 6 days ago
• Article
Link
高级开发人员难以把自己的专业性传达清楚，往往不是因为知识不足，而是因为他们与业务其他部门"说的是两种语言"。问题的核心在于框架不同：市场、销售、产品和高管关注的是如何快速把想法投到市场、尽快验证并减少不确定性；而高级开发关注的是管理复杂性以保证系统稳定。这种根本性的错位导致了冲突。当开发以维护成本或代码复杂性为由回绝新功能时，他们是在表达运营层面的担忧，但并未触及业务对不确定性的根本焦虑。
把业务想象成同时运行两条循环会更容易理解：一条是速度循环——快速探索市场、从反馈中学习、尽快降低不确定性；另一条是稳定循环——确保付费用户能持续获得可靠、可理解且可修复的服务。高级开发主要处在第二条循环，他们害怕复杂性，因为复杂性直接威胁到他们必须维护的稳定性。每增加一个功能或特殊用例，系统就更难理解、排查和维护，风险随之上升，客户服务也可能受到影响。
沟通失败正发生在这两条循环碰撞的地方。业务把新功能视为学习和减不确定性的机会；高级开发把同一请求视为可能破坏稳定性的复杂来源。对那些在时间和不确定性中奔跑的业务方而言，开发对复杂性的担忧常被看作阻挠。开发者在沟通上会失败，往往是因为他们只用内部的复杂性指标来解释问题，而没有承认业务试图减少不确定性的目标。
那么高级开发该如何更有效沟通？作者 Tuhin Nair 建议做一个简单但有力的重新表述：不要一上来就谈复杂性问题，而是把自己的方案用"减少不确定性"的角度来呈现。他提出的关键句是："我们能试试更快的方法吗？"这句话既承认了业务对速度的诉求，"更快"暗示有替代路径，"试试"接受不完美但可能"够用"。开发者可以借此倡导简化、复用现有工具或避免不必要的投入，同时把这些作为更快获得市场反馈的手段来表述。
但 AI 的兴起改变了这一动态。 AI 能让任何人快速生成代码，加速那个以速度和不确定性为主的业务循环，代价却是稳定性。 AI 往往会生成更难理解、调试与维护的代码，而且并不对所产出的系统承担责任。这使得高级开发的角色比以往更重要，但他们的工作也在从单纯的构建者转向以"编辑者"为主——对产出承担最终责任的人。
为此，Nair 提出一个结构性解决方案：把两条业务循环在系统层面解耦。设想有一个"速度"版本的系统，让 AI 代理、初级开发和非技术人员可以在其中快速构建并发布功能以获取市场反馈，而不必为长期稳定性担忧；验证有价值的功能再进入"规模"版本，由高级开发作为编辑进行策划，实现设计良好、稳定且易于理解的最终系统。这样，业务既能保持速度与试错的动力，高级开发也能在负责的系统设计和稳定性上发挥真正价值，通过落地的成果而非空谈复杂性来证明自己的作用。
Senior developers often struggle to communicate their expertise not because they lack knowledge, but because they speak a different language than the rest of the business. The core issue lies in how problems are framed. While marketers, salespeople, product managers, and executives are driven by the need to reduce uncertainty, getting ideas to market quickly to test what works, senior developers are focused on managing complexity to maintain system stability. This creates a fundamental misalignment. When developers push back on feature requests by citing maintenance costs or code complexity, they are expressing their own operational concerns, but failing to address the business core anxiety about uncertainty.
To understand this dynamic, it helps to think of a business as running in two simultaneous loops. The first loop is about speed, exploring the market, learning from feedback, and reducing uncertainty as fast as possible. The second loop is about stability, ensuring that paying customers continue to receive a reliable, understandable, and fixable service. Senior developers live primarily in the second loop, fearing the monster of complexity because it directly threatens the stability they are responsible for. Every new feature or special case added to a system makes it harder to understand, debug, and maintain, which increases risk and threatens the continued service of customers.
The communication failure happens when these two loops collide. The rest of the business sees a new feature request as an opportunity to learn and reduce uncertainty. The senior developer sees the same request as a source of complexity that could destabilize the system. This leads to a disconnect where developer concerns about complexity feel like stonewalling to business stakeholders who are racing against time and uncertainty. Developers fail when they try to explain away a business problem using their own internal metrics, focusing only on complexity management instead of acknowledging the business goal of uncertainty reduction.
So, how can senior developers communicate more effectively? The author, Tuhin Nair, suggests a simple but powerful reframing. Instead of leading with the problems of complexity, senior developers should present their solutions in terms of uncertainty reduction. The proposed magic phrase is, "Can we try something quicker?" This phrase acknowledges the business need for speed, "quicker" implies an alternative path, and "try" accepts imperfection while suggesting a potentially good enough solution. It allows a developer to advocate for simplification, re-using existing tools, or avoiding unnecessary work, all while framing these actions as a faster way to get the market feedback the business craves.
However, the rise of AI has disrupted this entire dynamic. AI accelerates the business loop of speed and uncertainty reduction by allowing anyone to generate code quickly, but it does so at the cost of stability. AI is a destabilizer, creating code that is often harder to understand, debug, and maintain. Crucially, AI takes no responsibility for the systems it helps create. This makes the senior developer role more critical than ever, but their job is shifting from being solely a builder to being primarily an editor, the person who takes on the responsibility for what gets built.
Nair proposes a structural solution to this problem: decoupling the two business loops into separate systems. Imagine a 'Speed' version of a system, where AI agents, junior developers, and non-technical staff can rapidly build and ship features for market feedback without worrying about long-term stability. This feeds into a 'Scale' version of the system, a well-designed, stable, and understandable version curated by senior developers acting as editor. Features get tested in 'Speed' and then, if they prove valuable, are properly integrated into 'Scale'. This way, the business gets its speed and momentum, while senior developers get the space to apply their expertise in responsible system design and stability, truly communicating their value through action rather than just words about complexity.
330 comments • Comments Link
• 专业知识深深植根于一种难以用语言完全表达或传递的内在"世界观模型"。因此，认为只要"说对话"就能传授专业能力的想法是有根本性缺陷的。虽然后设事实的知识可以传递，但那些把知识互相关联、形成直觉理解的深层认知无法直接传达。 AI 擅长处理事实性信息，却缺乏能带来出人意料但正确洞见的世界观模型，而真正的专家知识只能通过引导式学习和长期实践获得。
• "传输主义"——即相信词语能完美传递意义——是沟通专业知识的一大障碍。这与"隐性知识"概念相关：那种深植于个人经验、难以形式化的技能。有人甚至主张用诗歌来绕过这些局限，凸显出真正的专业知识多么内在且难以言说。
• 高级开发者必须在"回避者"（缩减范围）与"实验者"（增加复杂性）之间不断权衡，两者在不同环境下既可能有利也可能有害。环境至关重要：初创公司做出 MVP 与医疗设备制造商的决策逻辑完全不同。优秀的高级开发者知道何时坚持简洁，何时主张必要的复杂性，理解每个系统和产品都有其独特性。
• "速度"与"规模"的反馈循环构成软件开发中的根本张力。"速度"循环优化快速市场学习，"规模"循环则优化长期稳定性与可维护性。 AI 被视为促进"速度"循环的强大工具，便于快速试验，但在"规模"循环上表现欠佳，因为后者需要对权衡、风险与系统长期健康的深刻理解。危险在于，快速版本一旦上线便成为常态，而投入资源去构建可扩展版本的意愿往往消失。
• 专业知识的传递往往是单向的，高级开发者常感到自己的经验不被需要，甚至被更依赖自身或 AI 工具的初级人员排斥。许多高级开发者反映，初级人员不太愿意寻求指导，更倾向于使用 AI 或谷歌而不是与人交流。这种情况因双方都缺乏时间进行知识分享而加剧，并带有一种认为在 AI 时代机构知识价值降低的认知偏差。
• 虽然"速度"循环有利于学习，但它常把临时性解决方案永久化，产生大量技术债务和运营风险。尤其当管理层看到可运行的原型时，往往不愿再投入资源去做更稳健、可扩展的版本。因而高级开发者必须学会设计那种即便作为快速版本上线也不会"烧掉整栋楼"的方案——这是门微妙的艺术，而 AI 在这方面能力明显不足。
• 高级开发者的价值不仅在于技术能力，还在于他们驾驭业务环境的能力，包括理解激励、衡量权衡与预见长期后果。他们能对不合理要求说"不"，能从客户痛点或业务风险出发构建论据，并设计出"足够好"的系统，既能快速交付又不会危及公司未来。这种领导力难以被自动化取代。
• AI 的兴起并没有降低对高级开发者的需求，反而使他们的技能更为关键。 AI 可以快速生成代码，但缺乏承担责任、理解业务领域和在权衡取舍上作出细致判断的能力。高级开发者的角色正在演变为指导和审查 AI 生成的代码，确保其符合"规模"循环对稳定性、可维护性和长期健康的要求。
• 文章的核心信息是：高级开发者不仅仅是"慢"的人，他们对构建稳定、可维护、可扩展的系统至关重要，而这些特质往往与"快速行动、打破常规"的心态相冲突。"速度"循环有助于学习，但"规模"循环对长期成功同样不可或缺。组织面临的挑战是同时重视并投入两者，认识到速度版本只是手段，而非目的。
讨论表明，在 AI 时代软件开发的未来令许多人深感担忧，但达成了一个强烈共识：虽然 AI 能加速"速度"循环，但无法替代高级开发者所提供的细致判断、责任感与对"规模"循环的深刻理解。这一张力并非新事物，但 AI 使其更加突出，从而使高级开发者的作用比以往任何时候都更为关键。然而，高级开发者的价值常被初级人员和管理层低估，导致他们感到沮丧和被忽视。关键在于组织要更好地利用高级开发者的专业知识，不仅发挥他们的技术能力，更利用他们在速度与稳定性之间做复杂权衡的能力，确保构建出的系统既快速又可持续。 • Expertise is deeply tied to an internal "world model" that cannot be fully articulated or transferred through words alone, making the common belief that expertise can be communicated simply by "saying the right things" fundamentally flawed. While factual knowledge is transferable, the interconnected, intuitive understanding of what knowledge adds up to cannot be conveyed. AI excels at facts but lacks the world model that allows surprising correct insights, which is the essence of true expertise and can only be acquired through guided learning and effort.
• The "Transmissionist" belief, the idea that meaning is perfectly transferred through words, is a key barrier to communicating expertise. This is related to the concept of "tacit knowledge," knowledge that is deeply personal and hard to formalize. One insightful commenter even argues for communicating in poetry to bypass these limitations, highlighting how deeply embedded and non-verbalizable true expertise can be.
• A senior developer must constantly navigate the tension between "avoiders" (who reduce scope) and "experimenters" (who add complexity), as both can be beneficial or harmful depending on context. Context is paramount: a startup building an MVP needs different decisions than a medical device manufacturer. A good senior knows when to fight for simplicity and when to advocate for necessary complexity, understanding that every system and product is different.
• The "Speed" vs. "Scale" feedback loops represent a fundamental tension in software development, where the "Speed" loop optimizes for rapid market learning and the "Scale" loop for long-term stability and maintainability. AI is seen as a powerful tool for the "Speed" loop, enabling rapid experimentation, but it is currently poor at the "Scale" loop, which requires deep understanding of tradeoffs, risk, and long-term system health. The danger is that the "Speed" version, once in production, becomes permanent, and the investment in the "Scale" version is never made.
• Communicating expertise is often a one-way street, with seniors feeling their knowledge is unwanted or even resented by juniors who prefer self-reliance or AI tools. Many seniors report that juniors are uninterested in mentorship, don't seek out experienced colleagues, and are more comfortable with AI or Google than with human interaction. This is exacerbated by a lack of time for both parties to engage in knowledge sharing, and a perception that institutional knowledge has little value in the age of AI.
• The "Speed" loop, while valuable for learning, often leads to "temporary" solutions becoming permanent, creating massive technical debt and operational risk. This is especially true when leadership sees a working prototype and is unwilling to invest in a more robust, scalable version. The article argues that senior developers must design the "Speed" version in a way that, if it goes into production, won't "burn the building down," a subtle art that AI is currently atrocious at.
• The value of a senior developer lies not just in technical skill, but in their ability to understand and navigate the business context, including incentives, tradeoffs, and long-term consequences. This includes the ability to say "no" to unreasonable requests, to frame arguments in terms of customer pain or business risk, and to design systems that are "good enough" to ship fast without jeopardizing the company's future. This is a form of leadership that is difficult to automate.
• The rise of AI has not diminished the need for senior developers; in fact, it has made their skills more critical. While AI can generate code quickly, it lacks the ability to take responsibility, understand the business domain, and make nuanced judgments about tradeoffs. The senior developer's role is evolving to one of guiding and reviewing AI-generated code, ensuring it aligns with the "Scale" loop's requirements for stability, maintainability, and long-term health.
• The article's core message is that senior developers are not just "slow" developers, but are essential for building systems that are stable, maintainable, and scalable, qualities that are often at odds with the "move fast and break things" mentality. The "Speed" loop is valuable for learning, but the "Scale" loop is essential for long-term success. The challenge for organizations is to value and invest in both, and to recognize that the "Speed" version is a means to an end, not the end itself.
The discussion reveals a deep concern about the future of software development in the age of AI, with a strong consensus that while AI can accelerate the "Speed" loop, it cannot replace the nuanced judgment, responsibility, and deep understanding of the "Scale" loop that senior developers provide. The tension between these two loops is not new, but AI has amplified it, making the role of the senior developer more critical than ever. However, there is also a recognition that the value of senior developers is often underappreciated by both juniors and leadership, leading to frustration and a sense of being undervalued. The key takeaway is that organizations must find ways to better leverage the expertise of senior developers, not just for their technical skills, but for their ability to navigate the complex tradeoffs between speed and stability, and to ensure that the systems they build are not just fast, but also sustainable.