如何成为“不被卡住”的工程师
原始链接: www.seangoedecke.com/unblockable
只要用心，你就能做到“不被卡住”。换句话说，你可以让自己始终在目标上保持推进，不再停滞不前。
半个月前我在 为什么优秀的工程师很少被阻塞 一文中写过这个话题，现在我想再深入聊聊，给出一些更具体的建议。
同时处理多项任务
避免被卡住最简单的方法就是手里有多项任务。就像 CPU 线程一样，如果你同时负责多条工作流，当其中一条卡住时，你可以切换到另一条。虽然某个项目可能停滞了，但你没有：你仍在不断产出。
因此，我总是同时负责多个任务。但这里大有讲究。最糟糕的情况是同时负责两个紧急任务——无论你多努力，总有一个进度落后，这是大忌。同时进行太多任务也有风险，一旦其中一两个任务量突然膨胀，你就会超载（软件工程的工作量预估可是出了名的难）。你可能在一天内，从拥有两个轻松的小任务，变成同时面对三个大麻烦。
我不建议你随便从项目板上盲目地多领一个需求。 相反，你可以准备一些非项目类的辅助工作：比如代码重构、性能优化、写绩效评估、完成必修培训等。接新需求要讲策略，尽量避免同时处理两项重要的任务。
合理安排工作顺序
从一开始就规划好项目，将潜在的阻塞点降到最低。 这对你自己主导的项目尤为重要，但对于小任务也同样适用。
如果你觉得某件事可能会卡进度（例如，公司里的数据库迁移由专门团队负责，且排期很长），一定要越早做越好。这样你可以在等待他们处理的同时，继续推进项目的其他部分。一旦这一步搞错，可能会让项目白白延期好几周。同样，如果项目中某部分可能存在争议，也请尽早抛出来，这样在大家争论不休时，你还能继续完成其余的工作。
极度重视你的开发工具
不惜一切代价维护一个稳定、可靠的开发环境。这件事的重要性再怎么强调都不为过。开发环境的稳定性，直接决定了你一天能把多少时间花在真正的工作上。
例如，尽量使用最主流的开发技术栈。在 GitHub，大部分人在由服务器托管的开发容器平台 Codespaces 上进行开发。你可以用几乎任何 IDE 连接它，但绝大多数人都在用 VSCode，所以我也用 VSCode，并且尽量少装插件。很多开发者过于追求一切顺利时个人的“极致开发手速”，却低估了他们平时在调整配置、修补文件和排除环境故障上浪费了多少时间。
像对待生产环境事故一样，快速修复开发环境问题。 如果跑不了测试或本地服务，请立刻集中精力修好它，别半途而废。另一方面，别把它当成悠闲的学习机会（比如花半天去研究 MacOS 是怎么处理 Docker 网络的）。很多时候，全部推翻重装一遍，往往比死磕修补某个具体 Bug 更高效。
如果你的开发环境真的彻底瘫痪了——比如你在等新电脑，或者你正在修改一个你没有环境权限的临时服务——要想尽一切办法寻找替代方案。本地跑不了测试，GitHub CI 大概率能跑；本地起不来服务，能不能部署到测试环境去验证？遇到问题，花时间从根本上修复通常是最好的选择，但当你无能为力时，你应该发挥创意继续工作，而不是两手一摊直接放弃。
主动排查职责范围外的问题
我经常看到工程师遇到奇怪的问题——比如调用其他服务时返回 403 或 400 状态码——然后说：“哎呀，我被卡住了，我得找那个服务的负责人来看看。” 其实你可以，也绝对应该自己先去排查。
特别是当你有对方代码库权限时。既然报错了，就去搜搜他们的代码，看看什么会导致这个错误。翻翻你那条请求的日志，找找线索。当然，你挖得肯定不如懂行的工程师深，但解决你眼下这个具体的报错，通常并不需要多深的领域知识。
现在 AI 助手这么普及，你更没有借口退缩了。把问题代码丢给 AI（无论是 Codex、Copilot 还是 Claude Code），问它：“为什么我这个请求会报这个错？” 凭我的经验，大概有三分之一的情况它能给出正确答案，这简直是神器。与其等上几小时甚至几天去求人，不如花 10 分钟等 AI 跑结果，再花半小时验证它的答案。
退一步讲，即使你自己解决不了，你做的这些初步调研也能让你在寻求帮助时更有底气。对于服务负责人来说，收到一句“救命，我遇到了奇怪的 400 错误”非常令人沮丧——因为在定位问题甚至复现问题之前，他们必须先扒半天日志。但如果你的求助信息里直接附带了日志链接或具体的报错代码，他们立刻就知道该从哪儿下手了。
建立人际关系
在大厂做事通常有两种途径：明文规定的正式流程 和非正式渠道。例如，公司通常会有“求 Code Review”的 Slack 频道，里面满是等着审查代码的工程师。但很多聪明的工程师根本不用这些频道。他们会直接私聊别人帮忙看代码，速度快得多。
当然，你不能随便乱找不认识的工程师看你的 PR，这会让人非常反感。你必须和你想要合作的每一个代码库的工程师建立人际关系。如果你魅力四射，也许刷脸就行；但对于我们普通人来说，建立关系的途径就是让自己“变得有用”：及时清晰地回答其他团队的问题、帮他们查 Bug、帮他们审查代码等等。
科技公司里最高效的工程师，通常都与其他团队的工程师保持着极其良好的人际关系。 这并不是说他们凡事都走后门，而是他们有可以随时动用的个人关系网。如果你被其他团队的工作卡住了，有“内部人脉”会带来天壤之别。
结交强大的盟友
在大公司里，只要有足够的“空中支援”，几乎所有的阻碍都能被扫除。这通常指的是了解你项目、并且愿意利用自身影响力帮你扫清障碍的总监或 VP。比如，他们可以去给数据库团队的经理发消息：“嘿，能优先处理一下这个迁移任务吗？”，或者指派手下非常资深的工程师来平息那场耽误你进度的技术争论。
你不可能在所有事情上都获得这种高层支援——除非公司管理非常混乱，或者你跟高管关系极其铁。但你可以有意识地去做那些符合高管诉求的项目，这样你就有正当理由去请求支援并如愿以偿。我在 作为主任软件工程师，我如何影响科技公司的政治 一文中详细探讨过这个话题，一言以蔽之：诀窍在于兜里多揣几个项目点子，然后挑那些符合公司本月核心利益的去执行。
很多工程师完全不懂得利用手头的强力盟友。如果你正在负责一个高优先级的项目，负责该项目的高管其实没精力去密切跟踪你的进度。他们指望你在卡住时，能够主动跑去告诉他们你需要帮助。
而且，和跨团队工程师之间的人情往来不同，向高层请求支援并不会“消耗”你的人情。相反，它往往能积累信任——这证明你很有干劲、一心想推进工作，且足够聪明知道该找他们帮忙。只要你清楚说明需要他们做什么，高管们通常都非常乐意出面帮你搞定。
总结
为了尽量减少你被卡住的时间，我建议：
- 至少同时处理两项任务，一项卡住了就无缝切换到另一项。
- 合理安排工作顺序，尽早发现并启动那些可能卡人的环节。
- 把可靠的开发环境当成头等大事，尽量避免使用冷门小众的开发工具。
- 勇于越界，主动去排查不属于你负责的外部服务报错。
- 平时多与外部团队的工程师建立良好的互助关系。
- 必要时，善用高管的“空中支援”来帮你扫清障碍。
如果你喜欢这篇文章，可以考虑 订阅 我的邮件更新，或者把它 [分享到 Hacker News](news.ycombinator.com/submitlink?… unblockable)。以下是另一篇相关文章的预览：
我在代码审查中看到工程师常犯的错误
过去两年里，代码审查（Code Review）变得愈发重要。虽然用 LLM 生成代码变得轻而易举，但审查代码的难度依然没有降低。现在许多软件工程师花在审查自己 AI 工具生成代码上的时间，甚至等于或多于审查同事代码的时间。
我认为很多工程师做代码审查的方式并不正确。当然，代码审查有很多不同的流派，所以这主要代表了我个人的 工程品味。
继续阅读...
