Skip to content
←

필사 모드: 开发者的生产力与职业发展 — 10 倍工程师神话、Deep Work、AI 时代的学习、Staff 工程师、避免倦怠完全指南 (2025)

中文
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

一个 15 篇技术系列的终点：人

之前的 14 篇讲的是系统、语言、运行时和 AI。这一篇讲的是驾驭这些技术的人。

技术的半衰期很短。2020 年写下的 Angular.js 知识，到 2025 年几乎没有价值。但学习技术的方式、解决问题的态度、与同事协作的原则，半衰期很长。甚至在 AI 代替人写代码的时代，这个"元层"的价值反而更大。

本文的主题：

  • 真实生产力的结构
  • Senior、Staff、Principal 的实体
  • AI 时代的学习策略
  • 不倦怠地长期坚持的方法
  • 技术人的财务常识

Part 1 — 拆解"10 倍工程师"

神话的出处

1968 年的 "Exploratory Experimental Studies Comparing Online and Offline Programming Performance" 研究中，观察到开发者之间的生产力差异最高达 28 倍。此后"10 倍工程师"这个说法就固定下来了。

误解

  • "10 倍工程师的打字速度快 10 倍" — 假的。
  • "10 倍工程师写代码没有 bug" — 假的。
  • "10 倍工程师一个人全干" — 实际上恰恰相反。

实际的观察

高级工程师们表现出的共同特征：

  1. 更善于定义问题 — 在写代码之前先找到正确的问题。
  2. 善于"决定不做" — 移除不必要的工作。
  3. 看得见杠杆点 — 一次投入就能把整个团队的速度提升 10% 的事。
  4. 读得更多 — 读的和写的一样多。
  5. 很快承认"错了" — 不受沉没成本左右。
  6. 把同事的水平抬上去 — 不是自己的产出 x 1，而是整个团队变成 x 1.1。

10 倍工程师不是"写 10 倍代码的人"，而是把团队产出放大 10 倍的放大器。

Part 2 — Deep Work — 编码专注力的科学

Cal Newport 的主张

Deep Work（2016）： "深度沉浸状态下的 1 小时，比分心状态下的 4 小时更有价值"

干扰的成本

  • Task Switch Cost：研究显示是 10-20 分钟。
  • 1 条 Slack 通知 = 损失 15 分钟专注力。
  • 两个会议连着开 = 中间那 1 小时是废墟。

Maker's Schedule vs Manager's Schedule

Paul Graham（2009）：

  • Maker（工程师）：需要持续半天以上的时间块。
  • Manager：可以用 30 分钟一格的会议拼出一天。

这两者混在同一个日历上时，Maker 永远输。解法：

  • 把会议集中到下午。
  • 在日历上预约"专注块"。
  • 一天只看 3-4 次 Slack。

2024-2025 AI 时代的 Deep Work

"AI 处理杂活，所以 Deep Work 的时间会变多" → 部分正确。

但与 AI 的对话本身也可能变成浅层工作。如果只是不停地和 Cursor、Copilot 来回交换消息，结果反而是思考的深度变浅。

建议：

  • 用 AI 做初稿和自动化 → 由人做深度评审。
  • "要能解释 LLM 的输出为什么对、为什么错"，这才对学习有帮助。
  • 每周 1-2 次不用 AI 写代码 — 别让肌肉萎缩。

Part 3 — 级别框架 — Senior、Staff、Principal

Will Larson 的 Staff 工程师原型 (Staff Engineer, 2021)

四种原型：

  1. Tech Lead — 一个团队的技术方向。与一位高级经理配对。
  2. Architect — 影响多个团队的架构决策。
  3. Solver — 出现难题时被投入的解决者。团队归属不明确。
  4. Right Hand — 高管的左膀右臂。战略、执行、代理。

按级别的区分

级别范围判断影响力
Junior单个工单需要指导自己的代码
Mid功能单位自主自己的代码 + 团队一部分
Senior项目承担设计责任团队产出
Staff多个团队技术战略组织产出
Principal整个公司与业务连接公司方向

升到 Staff 级别的信号

  • 写代码的时间减少，文档、评审、协调增加。
  • 问题从"这个系统要怎么做"变成"我们到底该不该做这个"。
  • 跨越团队边界给出技术方向。
  • 从"不可或缺的人"变成做决定的人。

"技术领导力"的陷阱

  • 完全不写代码之后会失去现实感。
  • 只有影响力却没有权力的时候会挫败。
  • 没有政治技巧就做不出大的改变。

解法：每周仍有 20-30% 在写代码。政治技巧就去读组织心理学的书。

Part 4 — AI 时代的学习

没有变的东西

  • 基础知识的价值 — 分布式系统、数据库、算法、操作系统。这个系列讲过的一切。
  • 阅读理解能力 — 读懂论文和代码库的能力。
  • 写作 — 思考的清晰度会体现在文字里。
  • 沟通、谈判、反馈 — AI 无法代劳的东西。

变了的东西

  • 单纯记忆的价值下降 — 不用背 API 文档了。
  • 写 Boilerplate 的价值下降 — LLM 生成得很快。
  • 快速探索和实验的成本暴跌 — 一周的活一天做完。
  • "多语言工程师"变得自然 — 上下文切换成本下降。

用 AI 学习的方法

该做的：

  • 让 LLM 解释概念，然后带着怀疑去读那段解释。
  • 让 LLM 分析代码，然后和自己的理解做对比。
  • 把新技术当成小项目，和 LLM 结对去试。
  • 让 LLM 评审自己写的文字。

不该做的：

  • 不理解就复制粘贴 LLM 的输出。
  • 没有基础就直接跳到高级内容。
  • "AI 都帮我做了，我不懂也没关系" — 危险的错觉。

T 字型知识的重要性

  • 横向：宽广的系统理解（这个系列尝试覆盖的领域）。
  • 纵向：某一个领域的深度专长。

AI 时代里，横向 AI 能快速补上。纵向仍然是人的份内事。

Part 5 — 代码评审的经济学

用数字看效果

  • 修 bug 的成本：开发阶段 < 评审 < QA < 生产 = 1 : 5 : 25 : 125。
  • 评审是最便宜的发现 bug 的手段。

好评审的条件

  1. 24 小时内评审 — 再拖就会丢失上下文。
  2. 小 PR — 超过 400 行，评审质量急剧下降。
  3. 具体的反馈 — 不是"看着怪怪的"，而是"X 函数的 Y 情况没有处理"。
  4. 把情绪分开 — 对代码的批评不是对人的批评。
  5. 评审者也在学 — 读一个好的 PR 本身就是学习。

建立评审文化

  • PR 模板 — 背景、测试、部署影响。
  • 评审分配自动化（CODEOWNERS）。
  • "一次批准至少 2 人"这类政策要与规模匹配。

AI 代码评审

2024-2025 年的 GitHub Copilot Code Review、Graphite、CodeRabbit、Greptile。

  • 自动的风格检查和简单 bug 检查。
  • 人类评审者集中在架构、设计、业务背景上。
  • 但不要盲信 AI 的建议 — 有污染生产环境的风险。

Part 6 — 远程工作的原则

异步优先

  • 假设"所有人在同一时间在线"是做不到的。
  • 文档 > 会议。
  • 决策要留在文档里。Slack 消息会挥发。

文档的复利

高级工程师最大的杠杆是写作。写一次，就会被反复阅读。

  • RFC / ADR (Architecture Decision Record) 文化。
  • 设计文档模板。
  • 事后复盘制度化。

会议的 ROI

会议 = 时间 × 人数 × 时薪。6 个人开 1 小时的会 = 一个开发者一天的成本。

必须做到：议题文档、30 分钟以内、决策落到文档。

Part 7 — 不倦怠地长期坚持

倦怠的实体

  • 不只是身体能量的问题。
  • 认知能量 — 理解复杂代码的能力。
  • 情绪能量 — 与同事协作的能力。
  • 意志能量 — 做艰难决定的能力。

这四种里只要有一种枯竭，就会朝倦怠走去。

警告信号

  • 周末就开始害怕周一。
  • 被反馈刺伤得过分。
  • 冒出"我没用"的念头。
  • 睡眠质量下降。
  • 对爱好失去兴趣。

预防

  1. 有意留给能量恢复的时间 — 运动、睡眠、爱好。
  2. 让工作有"结束"的结构 — 可重复的每日例程。
  3. 练习拒绝 — 所有请求都接下来，倦怠就是必然。
  4. 把工作和自我分开 — 代码坏了，我不会跟着坏。
  5. 导师和同伴的网络 — 孤立会加速倦怠。

长期职业视角

"快速成长、快速烧完"通常走不过"以合适的速度走 20 年"。

真正顶尖的工程师们的共同点：过了三十五岁以后，学习曲线依然没有拐下去。这是因为在体力和精神健康上有长期投入。

Part 8 — 技术博客与演讲 — 复利型投资

为什么要写博客

  • 巩固学习 — 教是最快的学习方式。
  • 作品集 — 10 篇好文章胜过 50 个 GitHub 仓库。
  • 人脉 — 对同一主题感兴趣的人会找上门。
  • 机会 — 外部公司的招聘邀约、大会邀请。

博客的复利

写一次的文章能被读 5 年。累计读者数与时间 x 文章数成正比。

开始的建议：

  • 一开始哪怕只是自己的学习笔记的水平也没关系。
  • 频率比质量重要（最初的 1 年）。
  • SEO：把具体的错误信息、工具名放进标题。
  • 平台：GitHub Pages、Next.js + MDX、Hashnode、Medium（不太推荐）。

大会演讲

  • 从小型 meetup 开始。
  • 就同一个主题走完文章 → 内部分享 → 本地 meetup → 大会这几级台阶。
  • 准备成本很大，但之后机会的宽度会成比例地变大。

开源贡献

  • 与其给知名项目提一个大 PR，不如给每天在用的工具做一点小改进。
  • 截至 2024 年，在 GitHub 上点一个 "star" 花的时间是 0。真正有价值的是代码 PR。
  • 理解维护者的倦怠，友善地沟通。

Part 9 — 财务常识 — 工程师必须知道的东西

股票期权基础

  • ISO vs NSO（美国）：税务处理不同。
  • 4 年 vesting、1 年 cliff — 标准配置。
  • Strike Price：期权的行权价。越低越好。
  • 没有 Exit 就全是纸 — 很难变现。
  • 离职时 90 天的行权期限 → 2020 年代相当多的公司延长到了 10 年。

总薪酬的计算

  • 要看Base + Bonus + Equity + 福利的总和。
  • Equity 全看公司价值的前景。用当前 valuation 去除，就是上限。

薪资谈判

  • 拿到 offer 后等 24 小时 — 切忌当场答复。
  • 竞争性 offer 是最好的杠杆。
  • Base vs Equity vs Bonus 的分配是可以谈的。
  • Signing bonus + relocation 几乎肯定可以谈。

401k / IRA / 退休金

各国不同，但共通的是：尽可能把有税收优惠的账户填满。每年错过额度，复利上的损失会越来越大。

应急储备金

把6 个月的生活费放在流动资产里。被裁员或倦怠的时候，它会给你余地。

税

  • 做自由职业时，税务的基础知识是必须的。
  • 行权或卖出股票期权时，要在行权之前把税算清楚。之后就晚了。

Part 10 — 系列的收尾 — 回看 15 篇

这个系列从 Python 3.13 开始，经过 Core Web Vitals、PostgreSQL、Functional Programming、Kubernetes、Observability、WebAssembly、Edge Computing、CI/CD、Security、Distributed Systems、Database Internals、Messaging、Frontend State、Web Security 的攻击/防御、Network Engineering、Modern OS、Compiler/Runtime，一路走到了 AI Engineering。

把这 15 篇用一句话概括：

"2025 年的工程师是一种从协议到模型理解全栈，并基于这份理解去解决人的问题的存在"

技术是手段。目的是做出对人有用的东西。代码、架构、模型，全都是在这个目的之上才获得意义。

Part 11 — 职业检查清单（12 项）

  1. 每周的 Deep Work 时间块 — 预约到日历上。
  2. 每周写 1 份文档 — ADR、设计文档、博客文章。
  3. 把 1:1 开得有意义 — 和上级之间最大的杠杆。
  4. 每年 2-3 个学习目标 — 太多就会全部失败。
  5. 开源贡献的习惯 — 贡献给自己在用的工具。
  6. 技术博客每月至少 1 篇。
  7. 每周至少 3 次、每次 1 小时的运动 — 认知能力的下层结构。
  8. 7 小时以上的睡眠 — 生产力最上层的杠杆。
  9. 3 位以上的导师和同伴。
  10. 每季度回顾一次 5 年后的目标。
  11. 每年 1 次重新评估薪资和角色。
  12. 保持6 个月的应急储备金。

Part 12 — 十大职业反模式

  1. "只有现在这家公司才是我的价值" — 定期看看外部指标。
  2. 每个会议都参加 — 没有拒绝的肌肉 = 倦怠必然。
  3. 用提交数衡量生产力 — 最容易被误读的指标。
  4. 只追技术潮流 — 没有基础，潮流一变就得重来。
  5. 觉得一个人搞定才帅 — 求助不是弱点，是效率。
  6. 划线说"产品决策是 PM 的事" — Staff 及以上要共同承担产品责任。
  7. 不写东西 — 不写作却做到 Staff 以上的人很少。
  8. 不用 AI — 在 2025 年这意味着加班翻倍。
  9. 不加批判地接受 AI — 反方向的错误。质量急剧下降。
  10. 把自己的健康和财务推到"以后" — 最贵的一种拖延。

Part 13 — 推荐书目（够一个工程师读上十年的东西）

技术

  • Designing Data-Intensive Applications — Martin Kleppmann
  • The Pragmatic Programmer — Hunt & Thomas
  • Code Complete 2 — Steve McConnell
  • Clean Architecture — Robert Martin
  • Site Reliability Engineering — Google

职业与领导力

  • Staff Engineer — Will Larson
  • The Manager's Path — Camille Fournier
  • An Elegant Puzzle — Will Larson
  • The Phoenix Project / The Unicorn Project — Gene Kim
  • Accelerate — Forsgren, Humble, Kim

思考与生产力

  • Deep Work — Cal Newport
  • Atomic Habits — James Clear
  • Thinking, Fast and Slow — Daniel Kahneman
  • Getting Things Done — David Allen
  • Range — David Epstein

写作与沟通

  • On Writing Well — William Zinsser
  • The Sense of Style — Steven Pinker
  • Crucial Conversations — Patterson et al.

财务

  • The Simple Path to Wealth — JL Collins
  • The Psychology of Money — Morgan Housel

结语 — 技术人的长途旅程

技术是工具，职业是旅程。希望读着这个系列的你，在 1 年后、5 年后、10 年后，依然在学、在做、在分享。

最好的工程师是这样的人：

  • 保持谦逊的好奇心，
  • 在自己的健康上投资，
  • 把同事扶起来，
  • 在最无聊的问题里也能找到学习。

这个系列提供的技术知识，随着时间会有一部分变旧。但"学会了怎么学的人"永远能学会下一样东西。

2025 年 4 月，这个系列的 15 篇就此结束。感谢所有读过的人。

还有 — 愿你做出来的东西，能给这个世界带来一点点更好的不同。

系列索引

Python 3.13 • Core Web Vitals • PostgreSQL + pgvector • Functional Programming • Kubernetes Complexity • Observability • WebAssembly • Edge Computing • Modern CI/CD • Security & Zero Trust • Distributed Systems • Database Internals • Messaging & Streaming • Frontend State Management • Web Security Attacks/Defense • Network Engineering • Modern OS • Compiler & Runtime • AI Engineering • Developer Productivity & Career（本文）

현재 단락 (1/204)

之前的 14 篇讲的是系统、语言、运行时和 AI。这一篇讲的是**驾驭这些技术的人**。

작성 글자: 0자원문 글자: 6,857자작성 단락: 0/204