Writing

我在美国接触到的两类顶级程序员

FDE

大致可以分成两类。这里的分类不是严格按 title 来分，而是按能力重心来分：一种人擅长把模糊的业务问题快速变成可验证的产品；另一种人擅长把已经跑通的 workflow 沉淀成稳定、可复用、可扩展的系统。 大致可以分成两类。这里的分类不是严格按 title 来分，而是按能力重心来分：一种人擅长把模糊的业务问题快速变成可验证的产品；另一种人擅长把已经跑通的 workflow 沉淀成稳定、可复用、可扩展的系统。

第一类现在常被叫作 FDE（Forward Deployed Engineer）。其实在这个词流行之前，这类人就一直存在：很多 startup CTO、fractional CTO、早期 product engineer，本质上都在做类似的事情。他们的强项不是把系统一开始就设计得完美，而是在高度不确定的环境里，用最快的速度理解用户、判断商业价值，cut corners & ship fast。

他们往往很有企业家精神，喜欢直接和用户聊天，能在对话里迅速抓住 business context。技术上，他们通常偏好简单、直接、容易修改的方案。因为在 startup 早期，最大的风险往往不是代码不够优雅或者系统是不是能支持高并发、低延迟，而是做了很久才发现没有 product-market fit。这个阶段，过度追求严谨有时反而会变成成本：东西终于做出来了，钱也烧完了，用户却并不需要。

第二类是 platform engineer，也可以叫 principal engineer、staff engineer 或 software engineer。如果说 FDE 擅长把问题往前推，platform engineer 擅长的是在幕后把已经被验证过的 workflow 抽象、泛化，变成长期可运行的系统。他们做事看起来更慢，因为他们考虑的不只是“这个功能怎么做出来”，还包括：哪些能力应该沉淀成 core？哪些差异应该通过 adapter、config、route 或 policy 表达？这套系统换一个平台、客户或业务线时，还能不能低成本复用？

比如同样是一个客户要的新 app，product-facing engineer 可能会先做一个让客户满意的版本，把需求跑通；platform engineer 则会多想几层：UI 可以不同，但 backend 是否能共享？权限、数据模型、workflow、observability 是否应该统一？今天为了快而写死的逻辑，未来会不会让每个新需求都变成一次重写？

所以这两类人的差异，不是“一个快、一个慢”这么简单，而是他们负责的时间尺度不同。FDE 更关注从 0 到 1：这个问题是不是真的重要，用户能不能立刻变得更高效，产品有没有商业价值。Platform engineer 更关注从 1 到 N：当用户变多、需求变化、系统出错、团队交接之后，它还能不能继续可靠地运转。

但顶级工程师的共同点是，他们都会对质量负责，只是质量的含义不止是界面好不好看、功能能不能跑。它还包括更隐性的能力：

  • effectiveness：解决的是不是正确的问题，用户是否真的更高效。
  • performance：响应、吞吐、延迟是否撑得住真实使用。
  • security：权限、数据和攻击面是否可控。
  • reliability / availability：系统是否稳定，不轻易挂。
  • maintainability：代码和架构是否长期可维护。
  • observability：出问题时能否看见、定位、解释。
  • scalability：用户量或复杂度上来后是否还能扩展。
  • recoverability：失败后能否降级、恢复、回滚。
  • privacy / compliance：数据边界、权限和合规风险是否清楚。
  • cost efficiency：算力、存储和人力成本是否可控。

FDE 往往思维发散、爱好广泛，喜欢看 Hacker News，快速尝试新工具、新 framework，判断哪些东西能替代现有做法。但他们也知道，不是所有新东西都应该立刻进 production；有时候老的、冷门的工具反而更稳定。Platform engineer 则更倾向于长期阅读 platform-level 文档和 architecture，在一个技术栈里深耕，理解系统为什么这样设计，抽象边界在哪里，哪些 trade-off 不能轻易打破。

这两类人通常都不是朝九晚五意义上的工程师。公司也往往给他们很大的自由，因为他们对产品和代码的 ins and outs 足够熟悉，有自己的 code metrics、security standards 和 engineering guidance。他们还有一个共同点：都很“懒”。但这种懒不是少做事，而是讨厌重复劳动和做不必要的事，所以会不断做工具、抽象流程、自动化琐事。

这里还有一个核心差异，是他们对 maintainability 的优先级不同。startup CTO 可能更关注代码是否简单到一个新人 onboarding 后能立刻上手。platform engineer 更在意长期可维护性：当未来出现一百个相似但不完全相同的需求时，系统会不会被不断累积的 special case 撕碎。所以一个看似几行代码就能完成的功能，在他们手里可能会变成更复杂的抽象、更长的实现、更多的边界定义。短期看，这确实提高了理解门槛；长期看，它是在避免每个新客户、新平台、新流程都重新造一遍轮子。顶级工程师不一定同时精通两边，但会尊重另一边的约束：FDE 不会为了快而故意留下无法收拾的烂摊子，platform engineer 也不会为了抽象而抽象。