这是我在 Palantir 工作期间撰写的一份文档的修改版。
Stokes 是 Palantir 传奇般的 FDE，我通过效仿他的工作方式学到了很多。这并非个人崇拜——它是一种特定工作方式的代称，正是这种工作方式将卓越的 FDE 与其他人区分开来。
以下是定义这种方法的战术原则。
绝不走会累积恶果的捷径
- 不要做非产品默认配置的配置更改
- 永远不要“重启服务看看能不能修好”——你这是在销毁证据
- 永远不要部署脏构建。如果你在分支上，回到主线就是 P0 优先级
- 每一个定制修改都是带复利的技术债
掌控产品技术栈
- 克隆代码仓库，让它们能构建起来，开始提交 PR
- 拿到堆栈跟踪时，认真读它。在开工单之前先形成假设
- 熟记架构——当遥测失效时，它是你唯一的地图
- 如果某个工作流被一个功能阻塞，就自己评估范围并把它做出来
把信息当作基础设施
- 从第一天起就确保日志和指标被正确采集
- 精通遥测工具——它们不是可选项
- 阅读一切：文档、运维手册、发布说明、支持工单、Stack Overflow
- 关注其他团队遇到的问题——他们的麻烦很快就会变成你的麻烦
凡事追根溯源
- 永远不要把“现在能跑了”当作问题解决
- 在实施修复之前，先收集数据并形成假设
- 你必须能解释产品为什么会坏，以及你的修复为什么有效
- 为未来的自己记录调试过程
建立战略性关系
- 每一张支持工单都是与核心工程师建立关系的机会
- 向产品方向贡献一线信号——你是他们的眼睛和耳朵
- 了解产品团队的路线图，并基于部署实际情况发表意见
- 让你的工单被优先处理，靠的是关系，而不仅仅是严重程度
战略主线
这些并非随意的最佳实践。它们是能累积成战略优势的行为：对结果的彻底负责。
当你拒绝捷径时，你选择的是长期系统健康而非短期收益。当你精通产品技术栈时，你成为产品团队的同行者，而非消费者。当你凡事追根溯源时，你在积累机构知识，让未来的问题变得轻而易举。
这正是 FDE 模式的强大之处。你的存在不是为了实施解决方案——而是为了完全掌控结果。这种掌控体现在这些看似微小、却从根本上改变你工作方式的具体战术行为上。
问题不在于你能不能做到这些，而在于你会不会去做。
正在组建 FDE 团队？这些原则就是你的招聘标准。寻找已经这样思考的工程师。
这些原则构成了我的 FDE 面试评分表中的评估标准。
正在实施 FDE 招聘计划？请参阅我的 FDE 咨询资料，其中包含面试模板、评分卡和详细的流程指南。