反向压力(Backpressure)才是你真正需要的
本文提出使用编码 AI agent 的第三种方式——在人与 agent 之间建立"反向压力"机制,让 agent 自己先完成更多验证再交给人类审查。作者类比系统工程中的反向压力概念:当下游组件无法继续处理时,向上游发信号要求减速。在编码场景中,自动化测试、类型系统、CI 流水线都是反向压力。但当前用 LLM 写代码时,人类自己成了默认的反向压力——手动审查…
Lucas F. Costa 的博客,关于软件、创业与自我认知的辛辣洞见。
本文提出使用编码 AI agent 的第三种方式——在人与 agent 之间建立"反向压力"机制,让 agent 自己先完成更多验证再交给人类审查。作者类比系统工程中的反向压力概念:当下游组件无法继续处理时,向上游发信号要求减速。在编码场景中,自动化测试、类型系统、CI 流水线都是反向压力。但当前用 LLM 写代码时,人类自己成了默认的反向压力——手动审查…
设计文档不过是披着连帽衫的瀑布式开发。作者 Lucas F. Costa 以犀利个人观察指出:大多数 design doc 的真实功能不是指导实现,而是让组织感到安全——提供一个可审批、可追责的工件。你在信息最少的阶段被迫做最多决定,文档写完即弃无人更新。文章不空谈批判,给出具体替代方案:写问题而非解决方案、识别单向门/双向门决策、先原型再写文档、用代码审…
作者用犀利甚至带点愤怒的语气拆解了"写设计文档"这个工程标配实践的问题:大部分设计文档在第二个 sprint 就已过时、从没人回头更新、成为了 Google Drive 里的数字墓碑。他指出很多团队用写文档替代了真正的设计讨论和决策,文档写完就以为设计做完了。文章主张用更轻量的方式——面对面讨论、ADR(架构决策记录)、原型验证——来代替冗长的设计文档模板…
许多团队的回顾会议变成了形式主义——记录问题却从不解决,分配调查任务却无果而终。作者以亲身经历批判这种低效循环,并通过丰田生产方式(TPS)的"安灯拉绳"机制引出四个改进方向:1)赋予团队"拉停产线"的权力,如Resend公司的"The Fixer"轮值制度,每周指定专人全权负责修复问题;2)立即行动与尽早复盘,而非把问题推向下次回顾;3)将模糊的"调查"…
很多团队的回顾会沦为"记录没人修的问题"的形式主义。作者指出,回顾的本质是相信改进会发生,但现实中团队列出问题清单后却永远没有时间修复。文章给出了两种可行的改进方向:要么确保每次回顾产出可执行的小改进行动,要么直接将回顾与后续开发周期的工作项绑定,不让问题被遗忘。短而实用,有个人观察和具体操作方法。
作者自己的项目多次登上 HN 首页,这篇文章分享了具体可复用的经验和策略。内容包括:标题怎么写才不被改、什么时间点发布曝光最高、如何回复评论区的质疑来制造热度而非防御、以及为什么第一波 upvote 的节奏比内容本身更关键。全是第一手踩坑经验,不是泛泛而谈的"做好内容自然有人看"。对于想在海内外技术社区做冷启动的技术创作者来说,这篇有很高的实操参考价值。
核心看点:待办列表(backlog)永远不会减少,因为它本质是"我们想做的事"而非"我们能做的事"。作者指出待办列表导致焦虑、错误优先级和低质量交付,并提出替代方案:限制在制品数量、只保留即将做的少数事项、用"问题跟踪"代替"功能列表"。文中有个人经验和具体方法,观点鲜明,对每一个在排期泥潭中挣扎的工程师和产品经理都有直接参考价值。讨论入口强——任何经历过…
一篇讽刺味十足的反向指南。作者用幽默口吻列举团队如何"成功"扭曲 Scrum:把每日站会变成状态汇报、把 sprint review 变成演示表演、把 retrospective 变成互相甩锅。核心观点是 Scrum 的问题是它通常确实有效,这让很多爱发明轮子的技术人不爽。文章通过反例让读者对照反思自己的团队是否也在犯这些经典错误,语言生动有个人风格,适合…
一个直白到有点挑衅的论点:大多数团队选 Scrum 是因为别人替他们选了,而不是因为 Scrum 适合他们。作者对比了 Scrum 的固定节奏和看板的流动模型,认为很多团队的真正需求是限制 WIP、可视化瓶颈、持续交付——这些看板天然支持,而 Scrum 的 sprint 反而制造了不必要的紧迫感和任务堆积。文章有个人实践经历支撑,不是理论空谈,适合正处于…
作者认为截止日期毫无意义,反而导致加班、低质量交付和倦怠。建议用基于风险的交付、小批量迭代和持续价值交付替代固定截止日期,适合团队管理者反思进度管理。
作者14岁时为了在《仙境传说》中挂机打怪,自学编写外挂机器人,从而开启了编程之路。文章充满个人回忆和情感,描绘了从用户到创造者的转变,对游戏怀旧和编程新手有强烈吸引力。