职业与工作方法amyunger.com
我在 Heroku 担任 Staff 工程师的工作方式
How I operated as a staff engineer at Heroku
2020 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
作者 Amy Unger 回顾自己在 Heroku/Salesforce 担任 Staff Engineer 的工作方式：描述了这一角色的多种原型、职责边界，以及大量时间花在跨团队沟通、对齐业务与技术决策上。文章是少见的对“Staff 级工程师到底每天在干什么”的第一手坦诚记录。
为什么经久不衰：Staff/Principal 工程师的角色定义模糊，这篇来自亲历者的具体描述在 2020 和 2022 两次登上首页，至今仍是理解高级技术角色真实日常的参考。
HN 评论精选
长期任职的 Staff 工程师最适合承担“删代码”这一最难也最有价值的工作
我最近的一个想法是：靠长期任职获得 Staff/Principal 职位的工程师应该多删代码。删代码其实是项目中最难的事情之一——要安全地删，既需要对系统有深入细致的了解，也需要了解当初添加该功能时的背景和决策。长期任职的工程师正适合做这件事：他们记得当初对这个功能的期望以及它何时未能兑现，深知代码不是免费的，而是维护和复杂性的持续成本。这种工作不适合交给初级工程师，甚至资深工程师也常缺乏相应的背景和全局知识。只有长期任职的 Staff 工程师才能自信地说：这个功能失败了，我可以删掉它而不破坏任何东西。当有人提起沉没成本谬误、说还有用户在用这个功能时，也只有他们有足够的背景、威望和权威来回绝：不，这个功能失败了，只达到了我们预期的 1%，不值得持续的维护负担。
delete_more查看英文原文
A thought I had recently is that staff/principal engineers who got their position by long tenure (not hired recently) should delete more code. Deleting code is actually one of the most difficult things to do in a project. To do it properly and without risking breaking things, requires not only vast and detailed knowledge of the system, but also knowing the context and decision around when the feature was added. A long tenure engineer is the perfect fit for this. They know how to surgically remove the useless code. They remember all the hopes they had for the feature and when it failed to produce those results. They know well that code is not free, it's an ongoing cost to maintenance and complexity. This is not easy work to give to a junior. It's not even for senior engineers because they often lack the context and broad system knowledge. Only the long tenure staff engineer can confidently say, that feature failed, and I can remove it without breaking anything. If someone brings up sunken cost fallacy and how some users use the feature, only the long tenure staff has the background, respect, and authority to say, no this feature failed, it has 1% of the results we wanted, it's not worth the ongoing maintenance burden. A staff engineer is supposed to a team multiplier through code. People often think of designs, refactoring, helpful tools, architecture discussions and documents. And it's true, these are all code related things that can multiply a team's efforts when done well. But what better way to multiply a team's productivity than to reduce the size of the system? Think of how green field projects start. They feel so fast and progress is so quick. Then the features come, more and more, slowing down development with expanding system complexity and maintenance of code. How much faster and quicker can the team move after the staff engineer has reduced the system by 50%? It's like turning back the clock on an aging system. Suddenly it feels years younger, able to move quickly again, but this time with the right features in place from the experience of past years. And the team is happier, less useless code to wade through and understand, less strange bugs caused from code that supports a useless feature.
这类角色的最大挑战是孤独感，以及靠维护信任关系来支撑艰难对话
哇！作为拥有类似模糊头衔（“软件架构师”）的人，这是我看过的对这份工作最准确的描述之一。我的雇主远没有 Salesforce 那么大，很多事情会按比例缩小，但基本原理是一样的。这类角色最大的挑战是孤独感和看似无休止的冲突。你需要努力维护与产品/销售/项目管理等同事的个人关系，确保有足够的信任基础来进行艰难的对话。这很容易被忽视，而那些同事会开始觉得你总是在否定他们的想法。
etimberg查看英文原文
Wow! As someone who has one of these nebulous titles ("Software Architect"), this is one of the most accurate descriptions I've seen of what the job entails. My employer is nowhere near the size of Salesforce, so a lot of things scale down, but the basics are the same. I would say the biggest challenge with roles like this is the loneliness and what seems like constant conflict. One needs to work hard to keep up personal relationships with product/sales/project management/etc to ensure that the level of trust is there to be able to have the hard conversations. It is really easy to forget that, and a lot of those other folks start to feel like you're always just shooting down their ideas.
大公司最难的问题是社会性问题，但并非所有人都适合长期做这种工作
写得太好了。很多内容与我在 Amazon 担任 Principal Engineer 的经历非常相似。到了某个阶段你会意识到，大公司最难的软件工程问题其实是社会性问题，而这正是 Principal/Staff 工程师投入大部分精力的地方。就我个人而言，我最终实在受不了这种工作，回到了一线编程，这次是做科学项目，我快乐多了。
spenczar5查看英文原文
What a great writeup. A lot of it sounds very familiar to my experience as a principal engineer at Amazon. There’s a certain point at which you realize the hardest software engineering problems for a large company are social problems, and that’s what you devote most of your energy to as a PE (or, I guess, a Staff Engineer). Personally, I really didn’t have the stomach for the work, eventually; I have gone back to active programming, this time for scientific projects, and I am much happier.
用“你会为什么被问责”来定义 Staff 工程师的实际职责，反而最务实
在 Amy 列举的各类 Staff 工程师原型及其职责中，她很强调“你可能因什么而被问责”，我挺喜欢这种定义“实际工作”的方式。诚然，字面理解可能显得有毒，但说白了：Heroku/Salesforce 的 Staff 工程师年薪恐怕至少 40 万美元，你理应是在解决真正重大的问题。用“如果搞砸了你会被问责的事”来定义这些问题，是非常务实的写职位描述的方式。另外这句我也很喜欢：“首先，如果我共事的人理解业务决策如何与他们的日常工作挂钩，我就是成功的。”如果一个人对技术领导力只了解这一句话，他也立刻能跻身前四分之一的技术领导者。
ketzo查看英文原文
In Amy's list of different staff engineer archetypes and their responsibilities, she puts a lot of emphasis on "what you might be blamed for," which I actually really like as a way of defining what someone's "actual job" is. Sure, that could be toxic if you take it totally at face value. "Blame" has some nasty connotations. But let's face it: Staff engineer at Heroku/Salesforce is probably, what... $400k TC? At the very least? You are supposed to be someone who is solving seriously big problems. I think the most coherent way to write a job description is defining what those problems are, and "things you will be blamed for if they do not go right" is a very pragmatic way of defining those problems. Also: > First and foremost, I am successful if the folks I work with understand how business decisions tie into their day-to-day work. Love this. If this were the literal only sentence that a person knew about technical leadership in software engineering, they'd be instantly top quartile of technical leaders.
批评文章缺乏量化成果，且通篇显得自我拔高
这类文章读起来总有点自我祝贺和自我拔高……大谈作者如何游走于业务、管理、技术领导和架构的交汇点，却完全没有提到任何可衡量的数字或量化影响，也几乎不提这个角色的真实劣势和局限。而且有点奇怪的是，这个博客上几乎每篇文章都要提醒读者作者是 Staff 工程师、非常在意这个职位、非常懂这个角色、以及这个头衔有多难获得……
csmpltn查看英文原文
Something about these articles reads so self congratulatory and aggrandizing... A lot of talk about how the author lives on the cross section of business, management, technical leadership and architecture - but literally zero mention of any measurable numbers or quantifiable impact. Little to no mention of honest disadvantages and limitations of this role. I also find it a bit strange how literally every single article on https://amyunger.com/ reminds us that the author is a staff engineer, cares deeply about staff positions, very knowledgeable about the staff engineering role, and that it's oh-so-difficult to achieve this prestigious title...
历次讨论
同类还值得读
用十年时间自学编程（1998）
Teach Yourself Programming in Ten Years (1998)
Peter Norvig 1998 年的经典文章，回应“21天/24小时学会编程”一类速成书，主张真正精通编程需要约十年持续、有意识的练习。
职业与工作方法上首页 11 次 · 2007–2025norvig.com编辑精选如何成为一名程序员：简短、全面而个人的总结
How to be a Programmer: A Short, Comprehensive, and Personal Summary
一篇广为流传的程序员成长指南，作者以个人经验系统总结了成为优秀程序员所需的各项技能——从调试、测试、沟通到团队协作与身心健康。
职业与工作方法上首页 6 次 · 2008–2015samizdat.mines.edu编辑精选不要自称程序员
Don't Call Yourself a Programmer
经典职业建议文章劝软件工程师不要把自己局限在“程序员”这个标签上，而要从公司业务角度说明自己创造的价值；文中讨论了成本中心与利润中心、头衔、求职与职业选择，也顺带批评了学术界的价…
职业与工作方法上首页 5 次 · 2011–2021kalzumeus.com编辑精选创作者的日程与经理的日程
Maker's Schedule, Manager's Schedule (2009)
Paul Graham 在这篇文章里把时间表分成两类：管理者的日程以小时为单位，会议可以填满一天；创作者（程序员、写作者等）的日程则以半天为单位，需要长时间不被打断的连续块。
职业与工作方法上首页 5 次 · 2009–2021paulgraham.com编辑精选为什么程序员的薪酬不与生产力成正比
Why programmers are not paid in proportion to their productivity
讨论为什么程序员的薪酬往往不随其生产力成比例增长：生产力难以客观量化，薪酬更多受组织预算、岗位定价和个人议价能力影响。
职业与工作方法上首页 5 次 · 2009–2022johndcook.com