“我不知道，这是Claude写的”：一场工程师的认知危机
文章探讨了AI编程普及后工程师面临的“认知投降”危机。许多开发者因急于完成任务，让AI生成复杂代码后缺乏深入理解，导致在代码审查中无法回答基本架构问题，甚至将责任推给AI。作者引用Google工程师的观点和个人经历，强调开发者必须保持对代码逻辑的最终掌控力，区分“利用AI”与“被AI驱动”的界限。核心观点是：工程师不应丧失理解系统构建、权衡利弊和阅读代码的能力，这是职业生存的关键。
通讯管理器
Engineering Manager.dev，每周一期工程管理实战通讯，由仍在第一线从事管理工作的同行分享实用建议。
评论
点赞
收藏软件工程的“负配速”效应：慢下来才能跑更快
作者结合马拉松训练和团队管理经验，提出软件工程中的“负配速”策略。指出多数公司在AI浪潮中盲目求快，导致技术债务堆积（正配速），最终在后期维护中耗尽精力。相反，应像长跑高手一样，前期慢下来建立高质量上下文和规范，虽然短期看似缓慢，但能避免后期崩溃，实现长期更快的交付速度。文章强调用耐心构建基础，而非为了速度牺牲代码质量。 
工程师管理者将讨厌OpenClaw：警惕AI代理狂热背后的风险
作者基于过去AI项目盲目推进的教训，警告工程师管理者警惕OpenClaw引发的新一轮AI代理（Agent）狂热。文章指出，与被动聊天机器人不同，具备主动执行能力的Agent一旦出错后果更严重（如自动发邮件或部署）。虽然目前技术尚不成熟且存在风险，但管理层可能会因跟风要求集成此类功能。作者建议管理者必须提前介入讨论，理解技术边界与潜在破坏力，避免重蹈覆辙。
技术专家为何不擅表达？用“数据压缩”思维重构沟通
文章借用数据压缩的概念，解释了为什么技术背景强的工程师和管理者往往不擅长沟通。核心观点是：沟通本质上是信息的压缩与解压过程。技术人员倾向于过度压缩（导致信息丢失和误解）或过度解压（导致听众困惑）。文章提出管理者需要掌握两个技能：一是“压缩”，即将复杂的内心体验精简为对方能理解的清晰表达；二是“解压”，即通过倾听还原对方的真实意图。作者结合自己从工程师转型管理者的经历，指出这种认知偏差是造成职场冲突和效率低下的主要原因，建议通过换位思考和刻意练习来提升沟通效果。 
工程师搞崩生产环境后才懂的教训：备份、回滚等7条铁律
作者总结了软件工程师在搞崩生产环境后学到的7条“潜规则”。核心观点包括：出问题时先回滚再排查，而不是证明与自己无关；备份必须实际恢复过才算数；日志要写得便于搜索且不过度冗余；任何数据变更都要有经过测试的回滚计划；外部依赖必挂，需提前设计降级方案；高风险操作实行“双人复核”；临时修复往往变成永久债务，应避免过度Hack。文章结合个人踩坑经历，强调工程纪律和实战经验。
工程管理与为人父：第二次尝试的感悟
一位新任工程经理兼新手父亲分享第二次做管理和做父亲的感悟。核心观点是：相比第一次，第二次不再追求完美平衡，而是接受“扔球”和精力分配，依靠信任的团队和家庭支持系统来缓解焦虑。作者认为外界夸大了管理和育儿的痛苦，关键在于心理韧性和建立支持机制，而非独自硬扛。文中包含明显的 Linear 广告植入。 
别做工程经理：当前环境下IC比管理更明智
作者基于近期与朋友的讨论，认为当前不建议资深工程师转向管理岗。主要理由有三：一是技术迭代极快（如AI编程工具），管理者难以保持技术敏锐度和实验时间；二是管理层级扁平化，晋升通道变窄且竞争加剧；三是跨公司比较下，高级IC（独立贡献者）的薪酬往往高于同级别管理者。尽管作者本人因喜爱管理工作而选择留任，但他建议若内心真正渴望管理路径仍可尝试，否则应暂缓转型。
软件工程游戏：无尽的刷怪循环
文章以LitRPG游戏机制类比软件工程师的职业成长，指出从中级到高级需要大量经验值，但重复工作带来的收益递减，导致许多工程师卡在Senior职位多年无法晋升Staff。作者认为这反映了职业发展的停滞期，并建议管理者主动为团队设计更有挑战性的任务以促进成长，而非让工程师陷入无意义的重复劳动。 
软件工程师和管理者的Slack高效使用技巧
作者认为工程经理往往忽视异步沟通环境的优化，导致大量时间浪费在Slack上。文章分享了7个实用技巧来减少噪音和提高效率：1. 只显示未读对话；2. 按优先级和日常联系分组频道；3. 利用静音/取消静音功能批量处理低频信息；4. 从嘈杂线程中解脱；5. 使用消息提醒功能避免未读列表混乱；6. 使用/remind命令设置定时发送或自我提醒；7. 编辑所有部分以快速整理界面。核心观点是花少量时间建立流程，长期能节省大量精力。
该退役的工程教条：Sprint、无注释和第三方包
作者反思了软件工程中五个被视为常识但值得重新审视的实践。首先，盲目依赖第三方包（如left-pad事件）存在风险，LLM时代手写简单代码可能更可控。其次，强制的代码审查流程可能拖慢效率，建议信任工程师自主合并或采用结对编程。第三，传统的2-4周Sprint并非唯一选择，Basecamp的Shape Up模式提供了更灵活的替代方案。第四，滥用特性开关会导致代码库复杂化和虚假安全感，应适度使用而非覆盖所有变更。最后，关于代码注释，极端观点均不合理，适度的注释能节省未来维护成本。核心观点是工程师管理者需平衡教条与现实，根据团队情况定制最佳实践。
工程团队中的“隐形工作”陷阱
文章指出高级工程师晋升受阻往往是因为大量时间消耗在无法被量化的“隐形工作”中。作者将其归纳为三类：无记录的即时生产支持、作为团队粘合剂的代码审查与指导、以及为了质量而自行添加的非官方需求（影子待办）。这些工作不仅导致产能规划失真和资深员工倦怠，还使得绩效评估缺乏依据。解决之道在于降低记录门槛、轮岗分担粘合剂工作，并将影子需求纳入正式规划。文中包含明显的 Linear 软件推广内容。 
强制代码审查的代价：数据揭示的效率与质量博弈
作者基于对400多家公司和3000多名工程师的数据分析，重新审视了强制代码审查（Code Review）的价值。核心发现包括：不审查确实能提升近一倍的产出速度，但会导致2.4倍的Bug增加，且每专家小时的Bug率上升25%。审查的质量至关重要，高质量审查虽降低38%速度，但减少61% Bug。审查速度也是关键，3小时内完成的团队生产力是慢审团队的2.1倍。顶级团队能在保持Bug率更低的同时实现2.7倍的速度优势。文章建议废除“全员全量强制审查”，转向选择性、高质量且快速的审查机制，以平衡效率与质量。 
像组建地下城小队一样打造工程团队
作者借用RPG游戏职业概念，提出构建平衡的工程团队模型。包括负责攻坚的战士、执行稳定的坦克、维护士气的治疗者、擅长架构的法师和灵活的全栈盗贼。文章强调EM应避免只招同类高手，而要互补搭配，并反思自身角色以填补团队短板。观点清晰，具有实操参考价值，能引发关于团队组建的讨论。 
技术经理的AI落地指南：如何让工程师不再反感
文章为技术管理者提供了一套经过验证的AI落地五阶段框架。核心观点是：成功的关键在于将AI视为系统工程而非单纯的工具引入。具体包括：1. 组建小规模Alpha团队进行工具评估与规则定制；2. 利用MCP协议和上下文配置让AI适应现有工程环境；3. 引入后台Agent处理自动化任务；4. 建立基于代码审查质量和生产力的量化指标体系；5. 形成持续评估新工具的机制。作者强调，通过赋予工程师清晰的规则和上下文，可以消除抵触情绪并实现真正的ROI提升。
Agent时代的工程管理：为什么经理依然不可替代
作者认为即使编程Agent达到中级工程师水平，工程经理（EM）依然不可或缺。因为软件工程的本质是解决业务问题而非单纯写代码。EM的核心价值在于：1. 理解业务， bridging技术与商业；2. 明确需求定义，这对指导LLM工具至关重要；3. 处理人际冲突与期望管理，这是AI无法替代的社会技能。作者建议EM保持动手能力，结合软技能与技术视野，将在Agent时代更具竞争力。 
别再强迫你的工程师使用AI工具了
作者强烈反对管理层强制工程师使用AI工具。文章指出，盲目追求工具采用率会导致灾难，管理者应关注产出而非工具本身。建议给予团队时间探索适合自身业务的工作流，分享内部成功案例，而不是照搬外部做法。核心观点是：信任工程师的判断力，让工具服务于工作，而不是为了用AI而用AI。 
当产品经理接手工程团队：我的两年实战反思
一位从开发转产品再转工程经理的人分享实战经验。核心观点包括：让工程师直接与客户对话以验证假设，而非盲目执行需求；通过提问引导工程师关注业务价值而非单纯写代码；用产品语言解释技术债务（如部署稳定性）的价值以争取资源；拒绝看似有趣但无实际业务价值的技术项目。文章提供了具体的管理案例和思维转换方法。
软件工程师的“挤压”时代：平庸者退场，强者突围
文章认为软件工程不再是躺赚的行业，大量平庸工程师正被市场挤压。作者指出，过去低门槛导致人才泛滥，如今仅会写代码的“码农”面临失业风险，而具备产品思维和解决实际问题能力的优秀工程师依然稀缺。面对AI和就业寒冬，建议工程师停止抱怨，主动提升技能，拥抱变化，否则将被淘汰。
IKEA工程经理手记：在传统巨头做技术管理的真相与反思
IKEA集团数字化部门工程经理Nikolay分享在大型传统企业做技术管理的真实经验。核心观点包括：1. 面对遗留系统需保持谦逊，理解其历史价值而非盲目追求现代化；2. 工程师需深入业务，不能只做代码实现者，要具备产品思维；3. 通过强制轮岗零售一线来防止技术团队脱离实际；4. 技术选型不仅看成本，更看重实验带来的认知提升；5. 管理上应从“推动”转为“拉动”，通过提问激发团队思考而非直接给答案。文章提供了大厂非科技公司技术团队的独特管理视角和避坑指南。
用漫画解读软件工程的13条铁律：从康威定律到墨菲法则
作者以漫画形式梳理了13个软件工程领域的经典定律（如帕金森定律、布鲁克斯法则、康威定律等），并重点解释了它们对工程经理的实际意义。文章指出这些定律多为心智模型而非绝对真理，旨在帮助管理者在估算、团队规模、API设计和指标考核等方面避免常见陷阱，提升工程效率与决策质量。