beizhu
type
Post
status
Published
date
Jan 8, 2026
slug
summary
工程师的职业高度最终不取决于写代码的能力，而在于驾驭“代码之外”的复杂性（人、对齐、模糊性）。 作者建议技术人员从“痴迷技术”转向“深度理解用户问题”，坚持“清晰即资深”的极简编码原则，并将重心从单纯的执行速度转移到团队目标的“对齐”上。真正的资深工程师懂得通过写作和人脉积累复利，明白代码只是手段，而解决实际问题、降低运维风险以及提升团队影响力才是职业生涯中真正值得投资的资产。
tags
思考
category
心情随笔
icon
password
2026年1月3日
当我大约 14 年前加入谷歌时，我以为这份工作就是写出优秀的代码。我只对了一半。留在这里的时间越长，我就越意识到，那些发展得最好的工程师未必是编程技术最顶尖的——而是那些搞懂了如何驾驭代码之外一切事物的人：人际关系、办公室政治、目标对齐以及模糊性。
这些是我希望自己能早点知道的经验教训。其中一些如果早知道，本可以帮我省去几个月的挫折；另一些则花了我数年时间才完全领悟。这些都不是关于具体技术的——技术更新太快，根本不重要。这些经验关于那些在不同项目、不同团队中反复出现的模式。
我分享这些是因为我曾从为我指点迷津的工程师那里受益良多。就把这当作我传递这份善意的一次尝试吧。
1. 最好的工程师痴迷于解决用户问题
爱上一项技术并四处寻找它的应用场景是很诱人的。我干过这事，大家都干过。但那些创造了最大价值的工程师通常是反向工作（Work Backwards）：他们痴迷于深度理解用户的问题，让解决方案从理解中自然浮现。
“用户痴迷”意味着花时间看工单（support tickets），与用户交谈，观察用户的挣扎，直到问“为什么”问到触及根本。真正理解问题的工程师往往会发现，优雅的解决方案比任何人预期的都要简单。
而从解决方案出发的工程师，往往是为了给技术找理由而制造复杂性。
2. “你是对的”很廉价，“共同达成正确”才是真本事
你可以赢下每一场技术争论，却输掉整个项目。我见过才华横溢的工程师因为总是要在屋子里当那个“最聪明的人”，而积攒了同事们无声的怨气。这些代价稍后会以“神秘的执行问题”和“奇怪的阻力”的形式显现出来。
真正的技能不在于你是对的，而在于进入讨论时是为了**对齐（Align）**问题，给他人留出空间，并对自己确信的事情保持怀疑。
观点鲜明，但心态开放（Strong opinions, weakly held）——这不是因为你缺乏信念，而是因为在不确定性下所做的决定不应与你的个人身份绑定。
3. 行动至上。发布它。你可以修改一个糟糕的页面，但无法修改一张白纸
追求完美是令人瘫痪的。我曾见过工程师花数周时间为他们从未构建过的东西争论理想架构。完美的解决方案很少来自于纯粹的思考——它来自于与现实的碰撞。AI 在这方面其实能帮上大忙。
先做出来，再做对，最后做更好。把丑陋的原型推到用户面前；写下混乱的设计文档初稿；发布那个让你稍微有点尴尬的 MVP（最小可行性产品）。从一周的真实反馈中学到的东西，比一个月的理论辩论要多得多。
势能带来清晰，过度分析只会导致停滞。
4. 清晰即资深，炫技是负担
写出“聪明”代码的本能在工程师中几乎是普遍存在的。这感觉像是能力的证明。
但软件工程是编程加上时间和其他程序员的产物。在那种环境下，清晰度不是一种风格偏好——它是降低运维风险的手段。
你的代码是写给那些在凌晨 2 点处理故障的陌生人的战略备忘录。要为了他们的理解而优化，而不是为了你的优雅。我最尊敬的资深工程师都学会了每一次都用清晰去交换炫技。
5. 标新立异是一笔贷款，你要用故障、招聘难度和认知负担来偿还
把你的技术选型看作是一个只有少量“创新筹码”预算的组织。每当你采用实质上非标准的东西时，就花掉一个筹码。你负担不起太多。
重点不是“永远不要创新”，而是“只在你被付钱去创新的独特领域创新”。其他所有东西都应该默认选择“无聊”的技术，因为“无聊”意味着故障模式是已知的。
“最适合该工作的工具”往往是“跨多个工作中最不坏的工具”——因为维护一个技术栈的大杂烩（operating a zoo）才是真正的税负。
6. 代码不会为你代言，人会
在职业生涯早期，我相信优秀的工作成果会自己说话。我错了。代码只是静静地躺在仓库里。是你的经理在会议上提到你（或者没提）；是同事推荐你参与项目（或者推荐了别人）。
在大型组织中，决定是在你没被邀请的会议上做出的，使用的是你没写的摘要，由那些只有五分钟时间和十二个优先事项的人做出的。如果当你不在场时没有人能阐述你的影响力，那么你的影响力实际上就是可有可无的。
这不完全是关于自我推销，而是关于让价值链对每个人——包括你自己——都清晰可见（Legible）。
7. 最好的代码是你从未写过的代码
我们在工程文化中歌颂创造。没人因为删代码而晋升，尽管删代码往往比加代码更能改善系统。你没写的每一行代码，都是你永远不需要调试、维护或解释的一行。
在构建之前，穷尽这个问题：“如果我们……什么都不做会怎样？”有时答案是“没什么坏处”，那就是你的解决方案。
问题不在于工程师不会写代码（或用 AI 写代码），而在于我们太擅长写代码，以至于忘了问我们是否应该写。
8. 在规模化之下，连你的 Bug 都有用户
当用户足够多时，每一个可观察到的行为都会成为依赖——不管你原本承诺了什么。有人在爬取你的 API，自动化你的怪癖，甚至利用你的 Bug。
这带来了一个职业层面的洞察：你不能把兼容性工作视为“维护”，而把新功能视为“真正的工作”。兼容性就是产品。
要把废弃（Deprecations）设计成带有时间缓冲、工具支持和同理心的迁移。大多数“API 设计”实际上是“API 退休计划”。
9. 大多数“慢”的团队实际上是“未对齐”的团队
当项目拖沓时，本能反应是责怪执行力：大家工作不够努力，技术选型错了，工程师不够多。通常这些都不是真正的问题。
在大公司里，团队是你的并发单元，但随着团队数量倍增，协调成本呈几何级数增长。大多数缓慢实际上是对齐失败——人们在做错误的事情，或者用不兼容的方式做正确的事情。
资深工程师花在澄清方向、接口和优先级上的时间，比“更快地写代码”要多，因为那才是真正的瓶颈所在。
10. 关注你能控制的，忽略你不能控制的
在大公司里，无数变量是你无法控制的——组织架构调整、管理层决策、市场变动、产品转型。纠结于这些只会制造焦虑而无助于事。
那些保持理智和高效的工程师专注于他们的影响圈。你无法控制重组是否发生，但你可以控制你的工作质量、你的反应以及你学到了什么。面对不确定性时，把问题拆解，找出你可以采取的具体行动。
这不是被动接受，而是战略聚焦。花在无法改变之事上的精力，就是从可以改变之事上偷走的精力。
11. 抽象层不能消除复杂性，只是把它推迟到了你值班（On-call）的那天
每一个抽象层都是一个赌注：赌你不需要理解底层是什么。有时你赢了。但总会有东西“泄漏”（Leak），当这种情况发生时，你需要知道你站在什么之上。
资深工程师即使在技术栈越来越高层时，仍在不断学习“底层”知识。这并非出于怀旧，而是出于对那个抽象层失效、凌晨 3 点你独自面对系统的时刻的敬畏。使用你的技术栈，但要保留对其底层故障模式的思维模型。
12. 写作倒逼清晰，最好的学习方式是试着教别人
写作强迫你理清思路。当我在文档、演讲、代码审查评论中，甚至只是与 AI 聊天时向他人解释一个概念，我会发现我自己理解上的漏洞。让事情对别人清晰易懂的过程，也会让它对我自己更清晰。
这并不意味着你可以通过教别人来学会做外科手术，但在软件工程领域，这个前提基本成立。
这不仅仅是对知识的慷慨，这是一种自私的学习黑客技巧。如果你认为你理解了某样东西，试着简单地解释它。你卡壳的地方，就是你理解浅薄的地方。
教学是在调试你自己的思维模型。
13. 让其他工作成为可能的工作是无价的——也是隐形的
胶水工作（Glue work）——文档、入职培训、跨团队协调、流程改进——至关重要。但如果你无意识地做这些，它可能会阻碍你的技术晋升路径并让你精疲力竭。陷阱在于把它当作“乐于助人”，而不是把它当作深思熟虑、有边界、可见的影响力。
给它设定时间框（Timebox）。轮换着做。把它转化为产物：文档、模板、自动化工具。让它作为影响力被看见，而不是作为性格特征。
“无价且隐形”对你的职业生涯来说是一个危险的组合。
14. 如果你赢了每一次辩论，你可能正在积累无声的抵抗
我学会了怀疑自己的确定性。当我赢得太容易时，通常说明有问题。人们停止反驳你不是因为你通过道理说服了他们，而是因为他们放弃了尝试——他们会在执行中而不是会议上表达这种不同意。
真正的对齐需要更长时间。你必须真正理解其他视角，整合反馈，有时甚至公开改变主意。
短期内“我是对的”的爽感，远不如长期内与意愿一致的合作者一起构建事物的现实来得有价值。
15. 当一个指标成为目标时，它就不再是一个好的度量标准
你向管理层展示的每一个指标最终都会被博弈（Gamed）。并非出于恶意，而是因为人类会针对被度量的东西进行优化。
如果你追踪代码行数，你会得到更多行代码。如果你追踪开发速度（Velocity），你会得到注水后的估时。
资深的做法：对每一个指标要求都用一对指标来回应。一个针对速度，一个针对质量或风险。然后坚持解读趋势，而不是盲目崇拜阈值。目的是获得洞察，而不是监控。
16. 承认你不知道比假装知道更能创造安全感
说“我不知道”的资深工程师不是在示弱——他们是在创造许可。当一个领导者承认不确定性时，它向房间里的其他人发出了信号：这样做是安全的。反之，则是一种每个人都假装懂、问题被隐藏直到爆炸的文化。
我见过最资深的人从不承认困惑的团队，我也见过其造成的破坏。问题没人问，假设没人挑战。初级工程师保持沉默，因为他们以为其他人都懂。
以身作则表现出好奇心，你会得到一个真正学习的团队。
17. 你的关系网比你做的任何一份工作都长久
在职业生涯早期，我专注于工作而忽视了社交。事后看来，这是个错误。那些投资于人际关系——公司内部和外部——的同事获得了数十年的回报。
他们最先听到机会，能更快地建立桥梁，被推荐担任职位，并与多年建立信任的人共同创业。
你的工作不是永远的，但你的关系网是。带着好奇心和慷慨去经营它，而不是交易性的钻营。
当需要离开的时候，往往是人际关系为你打开大门。
18. 大多数性能提升来自于减少工作，而不是增加巧思
当系统变慢时，本能反应是做加法：缓存层、并行处理、更聪明的算法。有时这是对的。但我见过更多的性能胜利来自于问：“我们在计算什么不需要计算的东西？”
删除不必要的工作几乎总是比更快地做必要的工作更有影响力。最快的代码是从不运行的代码。
在你优化之前，先质疑这项工作是否应该存在。
19. 流程的存在是为了减少不确定性，而不是为了留痕
最好的流程让协作更容易，让失败的代价更低。最坏的流程是官僚主义的表演——它的存在不是为了提供帮助，而是为了在出问题时分配责任。
如果你不能解释一个流程如何降低风险或增加清晰度，它可能只是纯粹的负担。
如果人们花在记录工作上的时间比做工作的时间还多，那就是哪里出了大问题。
20. 最终，时间变得比金钱更值钱。据此行动
在职业生涯早期，你用时间换钱——这没问题。但在某个时刻，计算方式反转了。你开始意识到时间是不可再生资源。
我曾看着资深工程师为了追求下一个晋升等级、为了优化哪怕几个百分点的薪酬而耗尽自己。有些人得到了。大多数人在事后怀疑，这是否值得他们所放弃的东西。
答案不是“不要努力工作”。而是“知道你在交换什么，并深思熟虑地进行交换。”
21. 没有捷径，但有复利
专业技能来自于刻意练习——稍微超出你当前的能力范围，反思，重复。持续数年。没有浓缩版。
但这里有充满希望的部分：当学习创造了新选项而不仅仅是新琐事时，学习会产生复利。写作——不是为了流量，而是为了清晰。构建可复用的原语。把伤疤收集起来变成行动指南。
把职业生涯视为复利而非彩票的工程师，往往最终会走得更远。
最后的想法
21 条经验听起来很多，但它们归根结底就是几个核心理念：保持好奇，保持谦逊，并记住工作始终是关于人的——你为之构建产品的用户，以及与你一起构建产品的队友。
工程职业生涯足够长，足以让你犯很多错误并依然能脱颖而出。我最钦佩的工程师不是那些每件事都做对的人——而是那些从错误中学习、分享发现并坚持在场的人。
如果你在旅程的早期，要知道随着时间的推移它会变得更丰富。如果你已经深入其中，我希望其中一些能引起你的共鸣。
以下为原文：
When I joined Google ~14 years ago, I thought the job was about writing great code. I was partly right. But the longer I’ve stayed, the more I’ve realized that the engineers who thrive aren’t necessarily the best programmers - they’re the ones who’ve figured out how to navigate everything around the code: the people, the politics, the alignment, the ambiguity.
These lessons are what I wish I’d known earlier. Some would have saved me months of frustration. Others took years to fully understand. None of them are about specific technologies - those change too fast to matter. They’re about the patterns that keep showing up, project after project, team after team.
I’m sharing them because I’ve benefited enormously from engineers who did the same for me. Consider this my attempt to pay it forward.
1. The best engineers are obsessed with solving user problems.
It’s seductive to fall in love with a technology and go looking for places to apply it. I’ve done it. Everyone has. But the engineers who create the most value work backwards: they become obsessed with understanding user problems deeply, and let solutions emerge from that understanding.
User obsession means spending time in support tickets, talking to users, watching users struggle, asking “why” until you hit bedrock. The engineer who truly understands the problem often finds that the elegant solution is simpler than anyone expected.
The engineer who starts with a solution tends to build complexity in search of a justification.
2. Being right is cheap. Getting to right together is the real work.
You can win every technical argument and lose the project. I’ve watched brilliant engineers accrue silent resentment by always being the smartest person in the room. The cost shows up later as “mysterious execution issues” and “strange resistance.”
The skill isn’t being right. It’s entering discussions to align on the problem, creating space for others, and remaining skeptical of your own certainty.
Strong opinions, weakly held - not because you lack conviction, but because decisions made under uncertainty shouldn’t be welded to identity.
3. Bias towards action. Ship. You can edit a bad page, but you can’t edit a blank one.
The quest for perfection is paralyzing. I’ve watched engineers spend weeks debating the ideal architecture for something they’ve never built. The perfect solution rarely emerges from thought alone - it emerges from contact with reality. AI can in many ways help here.
First do it, then do it right, then do it better. Get the ugly prototype in front of users. Write the messy first draft of the design doc. Ship the MVP that embarrasses you slightly. You’ll learn more from one week of real feedback than a month of theoretical debate.
Momentum creates clarity. Analysis paralysis creates nothing.
4. Clarity is seniority. Cleverness is overhead.
The instinct to write clever code is almost universal among engineers. It feels like proof of competence.
But software engineering is what happens when you add time and other programmers. In that environment, clarity isn’t a style preference - it’s operational risk reduction.
Your code is a strategy memo to strangers who will maintain it at 2am during an outage. Optimize for their comprehension, not your elegance. The senior engineers I respect most have learned to trade cleverness for clarity, every time.
5. Novelty is a loan you repay in outages, hiring, and cognitive overhead.
Treat your technology choices like an organization with a small “innovation token” budget. Spend one each time you adopt something materially non-standard. You can’t afford many.
The punchline isn’t “never innovate.” It’s “innovate only where you’re uniquely paid to innovate.” Everything else should default to boring, because boring has known failure modes.
The “best tool for the job” is often the “least-worst tool across many jobs”-because operating a zoo becomes the real tax.
6. Your code doesn’t advocate for you. People do.
Early in my career, I believed great work would speak for itself. I was wrong. Code sits silently in a repository. Your manager mentions you in a meeting, or they don’t. A peer recommends you for a project, or someone else.
In large organizations, decisions get made in meetings you’re not invited to, using summaries you didn’t write, by people who have five minutes and twelve priorities. If no one can articulate your impact when you’re not in the room, your impact is effectively optional.
This isn’t strictly about self-promotion. It’s about making the value chain legible to everyone- including yourself.
7. The best code is the code you never had to write.
We celebrate creation in engineering culture. Nobody gets promoted for deleting code, even though deletion often improves a system more than addition. Every line of code you don’t write is a line you never have to debug, maintain, or explain.
Before you build, exhaust the question: “What would happen if we just… didn’t?” Sometimes the answer is “nothing bad,” and that’s your solution.
The problem isn’t that engineers can’t write code or use AI to do so. It’s that we’re so good at writing it that we forget to ask whether we should.
8. At scale, even your bugs have users.
With enough users, every observable behavior becomes a dependency - regardless of what you promised. Someone is scraping your API, automating your quirks, caching your bugs.
This creates a career-level insight: you can’t treat compatibility work as “maintenance” and new features as “real work.” Compatibility is product.
Design your deprecations as migrations with time, tooling, and empathy. Most “API design” is actually “API retirement.”
9. Most “slow” teams are actually misaligned teams.
When a project drags, the instinct is to blame execution: people aren’t working hard enough, the technology is wrong, there aren’t enough engineers. Usually none of that is the real problem.
In large companies, teams are your unit of concurrency, but coordination costs grow geometrically as teams multiply. Most slowness is actually alignment failure - people building the wrong things, or the right things in incompatible ways.
Senior engineers spend more time clarifying direction, interfaces, and priorities than “writing code faster” because that’s where the actual bottleneck lives.
10. Focus on what you can control. Ignore what you can’t.
In a large company, countless variables are outside your control - organizational changes, management decisions, market shifts, product pivots. Dwelling on these creates anxiety without agency.
The engineers who stay sane and effective zero in on their sphere of influence. You can’t control whether a reorg happens. You can control the quality of your work, how you respond, and what you learn. When faced with uncertainty, break problems into pieces and identify the specific actions available to you.
This isn’t passive acceptance but it is strategic focus. Energy spent on what you can’t change is energy stolen from what you can.
11. Abstractions don’t remove complexity. They move it to the day you’re on call.
Every abstraction is a bet that you won’t need to understand what’s underneath. Sometimes you win that bet. But something always leaks, and when it does, you need to know what you’re standing on.
Senior engineers keep learning “lower level” things even as stacks get higher. Not out of nostalgia, but out of respect for the moment when the abstraction fails and you’re alone with the system at 3am. Use your stack.
But keep a working model of its underlying failure modes.
12. Writing forces clarity. The fastest way to learn something better is to try teaching it.
Writing forces clarity. When I explain a concept to others - in a doc, a talk, a code review comment, even just chatting with AI - I discover the gaps in my own understanding. The act of making something legible to someone else makes it more legible to me.
This doesn’t mean that you’re going to learn how to be a surgeon by teaching it, but the premise still holds largely true in the software engineering domain.
This isn’t just about being generous with knowledge. It’s a selfish learning hack. If you think you understand something, try to explain it simply. The places where you stumble are the places where your understanding is shallow.
Teaching is debugging your own mental models.
13. The work that makes other work possible is priceless - and invisible.
Glue work - documentation, onboarding, cross-team coordination, process improvement - is vital. But if you do it unconsciously, it can stall your technical trajectory and burn you out. The trap is doing it as “helpfulness” rather than treating it as deliberate, bounded, visible impact.
Timebox it. Rotate it. Turn it into artifacts: docs, templates, automation. And make it legible as impact, not as personality trait.
Priceless and invisible is a dangerous combination for your career.
14. If you win every debate, you’re probably accumulating silent resistance.
I’ve learned to be suspicious of my own certainty. When I “win” too easily, something is usually wrong. People stop fighting you not because you’ve convinced them, but because they’ve given up trying - and they’ll express that disagreement in execution, not meetings.
Real alignment takes longer. You have to actually understand other perspectives, incorporate feedback, and sometimes change your mind publicly.
The short-term feeling of being right is worth much less than the long-term reality of building things with willing collaborators.
15. When a measure becomes a target, it stops measuring.
Every metric you expose to management will eventually be gamed. Not through malice, but because humans optimize for what’s measured.
If you track lines of code, you’ll get more lines. If you track velocity, you’ll get inflated estimates.
The senior move: respond to every metric request with a pair. One for speed. One for quality or risk. Then insist on interpreting trends, not worshiping thresholds. The goal is insight, not surveillance.
16. Admitting what you don’t know creates more safety than pretending you do.
Senior engineers who say “I don’t know” aren’t showing weakness - they’re creating permission. When a leader admits uncertainty, it signals that the room is safe for others to do the same. The alternative is a culture where everyone pretends to understand and problems stay hidden until they explode.
I’ve seen teams where the most senior person never admitted confusion, and I’ve seen the damage. Questions don’t get asked. Assumptions don’t get challenged. Junior engineers stay silent because they assume everyone else gets it.
Model curiosity, and you get a team that actually learns.
17. Your network outlasts every job you’ll ever have.
Early in my career, I focused on the work and neglected networking. In hindsight, this was a mistake. Colleagues who invested in relationships - inside and outside the company - reaped benefits for decades.
They heard about opportunities first, could build bridges faster, got recommended for roles, and co-founded ventures with people they’d built trust with over years.
Your job isn’t forever, but your network is. Approach it with curiosity and generosity, not transactional hustle.
When the time comes to move on, it’s often relationships that open the door.
18. Most performance wins come from removing work, not adding cleverness.
When systems get slow, the instinct is to add: caching layers, parallel processing, smarter algorithms. Sometimes that’s right. But I’ve seen more performance wins from asking “what are we computing that we don’t need?”
Deleting unnecessary work is almost always more impactful than doing necessary work faster. The fastest code is code that never runs.
Before you optimize, question whether the work should exist at all.
19. Process exists to reduce uncertainty, not to create paper trails.
The best process makes coordination easier and failures cheaper. The worst process is bureaucratic theater - it exists not to help but to assign blame when things go wrong.
If you can’t explain how a process reduces risk or increases clarity, it’s probably just overhead.
And if people are spending more time documenting their work than doing it, something has gone deeply wrong.
20. Eventually, time becomes worth more than money. Act accordingly.
Early in your career, you trade time for money - and that’s fine. But at some point, the calculus inverts. You start to realize that time is the non-renewable resource.
I’ve watched senior engineers burn out chasing the next promo level, optimizing for a few more percentage points of compensation. Some of them got it. Most of them wondered, afterward, if it was worth what they gave up.
The answer isn’t “don’t work hard.” It’s “know what you’re trading, and make the trade deliberately.”
21. There are no shortcuts, but there is compounding.
Expertise comes from deliberate practice - pushing slightly beyond your current skill, reflecting, repeating. For years. There’s no condensed version.
But here’s the hopeful part: learning compounds when it creates new options, not just new trivia. Write - not for engagement, but for clarity. Build reusable primitives. Collect scar tissue into playbooks.
The engineer who treats their career as compound interest, not lottery tickets, tends to end up much further ahead.
A final thought
Twenty-one lessons sounds like a lot, but they really come down to a few core ideas: stay curious, stay humble, and remember that the work is always about people - the users you’re building for and the teammates you’re building with.
A career in engineering is long enough to make plenty of mistakes and still come out ahead. The engineers I admire most aren’t the ones who got everything right - they’re the ones who learned from what went wrong, shared what they discovered, and kept showing up.
If you’re early in your journey, know that it gets richer with time. If you’re deep into it, I hope some of these resonate.