职业与工作方法mtlynch.io
我为何离开 Google 为自己工作
Why I Quit Google to Work for Myself
2018 — 2024，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
作者讲述自己从谷歌辞职自立门户的经历：在谷歌期间他投入大量时间修复构建系统故障、写文档、帮助同事，却因缺乏可量化的指标而在晋升中吃亏，加上频繁的组织重组让他失去动力，最终选择离开。文章引发了许多大公司工程师的共鸣。
为什么经久不衰：它触及大公司里“不可量化的贡献得不到回报”这一长期痛点，几乎每个在大组织工作过的人都能从中看到自己的影子，因此多年反复被顶上首页。
HN 评论精选
建议引入“助攻”式指标来衡量和奖励帮助他人的贡献
“我大幅减少了开发者在修复故障上花的时间，但没有任何指标追踪开发者的时间投入。”——连续几份工作里，我都觉得帮助团队其他人的价值被低估、也未被记录。我一直打算在自己团队里推行类似篮球“助攻”的指标：每人拿到一组助攻积分，必须分配给帮助自己最多的人。虽然我不喜欢游戏化的做法，但我工作过的地方都过度激励个人成就（尤其在晋升上），而对团队合作缺乏具体、可衡量的支持。有人试过这类团队协作指标吗？
dahart查看英文原文
> I drastically reduced the time developers spent repairing those failures, but there were no metrics that tracked developer time. For several jobs in a row, I've felt that helping others on a team is undervalued and under-recorded. I've been planning to implement the "assist" metric, similar to basketball, on my own team for a while. The idea would be something along the lines of everyone gets a set of assist points they must distribute to people who help them the most. While I don't love the idea of gamifying it, all the places I've ever worked have had too strong of a reverse incentive towards individual achievement, especially when it comes to promotion, and not nearly enough support for teamwork in specific and measurable ways. Anybody have experience with teamwork metrics like this, or others that worked or didn't work?
认为作者输在职场政治上，并劝告自立门户未必优于留在好公司
对作者说：你输掉的是政治游戏。我曾在创业公司拼命多年，同样输掉了政治游戏，所以这是经验之谈。你可以为此愤怒、固执、拒绝改变，浪费掉几年职业生涯；也可以学会怎么玩这个游戏。至于“为自己工作”，其实没人真正为自己工作——你要面对客户；而且除非你有非常明确的计划，在一家好公司工作要好得多：收入之外，大公司还能带来人脉和信誉，对之后找工作、融资、招人都有帮助。我只是想帮你省下几年弯路。
eldavido查看英文原文
To author: you lost the political game. I busted my ass at a startup for years and also lost the political game. So I'm speaking from experience here. You can either get all mad and worked up and pissed off about it, and waste years of your career (as I did) being pissed off, stubborn, and refusing to change. Or figure out how to play. I'd like to think there are places with better politics but I think it's pretty endemic of large organizations. I'd love to be proven wrong. The thing is, "working for yourself" is so flawed in so many ways. In the first place, nobody "works for themself". You might work for customers, or clients, or whatever, but not "yourself". Second, you're a lot better off working at a good company -- MUCH better off -- unless you have a pretty damn concrete idea of what you're doing. In addition to the income, the big company will provide better networking, more credibility for anything you do subsequently (whether a new job, fundraising, hiring--ANYTHING), it's an all-around better gig. I'm just trying to save you a lot of wasted years and time here. Take it or leave it.
在微软有几乎相同的经历：付出被认可却因制度原因无法晋升，最终离职
这篇文章和我几年前在微软的经历惊人地相似：不断的重组导致项目被砍，几个月的心血因管理层不清晰的决策付诸东流，让人失去动力。我也曾期待晋升到高级级别：我是五人团队里唯一非高级的开发者，竭尽全力按时交付了设计良好、测试完善的系统，甚至我坚持的一个设计决策在发布时避免了宕机。绩效评审我连续几年拿到最高档，却被告知“距上次升级时间不够”，再等一两年才行。那种挫败感难以形容，几个月后我就辞职了。最令人不快的是，离职面谈时我的隔级上司突然表示所有晋升大门都敞开——和雇主谈判的感觉竟像跟有线电视公司讨价还价。
martinraag查看英文原文
The article really resonated with me, as it's eerily similar to my own experience at Microsoft a couple of years back. Constant reorgs, resulting in projects being cancelled, resulting in lack of motivation, as months of your hard work are thrown out due to unclear decisions by the management. I too was hoping for a senior level promotion. The last project I worked on, I was the only non-senior level developer in a team of 5. I went out of my way to ensure we released a well designed, built and tested system on time. At times I felt like I was committing more to the project than any of my more senior comrades. Come release time, I even saw one of the design decisions I had insisted on save us from down-time. All of this I was sure would lead me to the desired promotion. Come performance review time, I was rated at the top performance tier, as I had the past couple of years. Unfortunately however, I was informed not enough time had passed since my last level increase, but I was sure to get it if I kept it up for another 1-2 years. It's hard to describe the feeling of defeat I felt at that point. I resigned and left within the next few months. What I found most off putting, was when meeting my skip-manager (your managers manager) for the first time during my exit interview, all doors for a senior level promotion were suddenly open, to incentivise me to stay. Doesn't feel great when negotiations with your employer are comparable to those had with your cable provider.
认为晋升委员会的判断有其道理，真正的问题是大公司的频繁重组
写文档、修 bug 确实不是高级工程师的晋升门槛，这点我不反对晋升委员会。高级工程师是终级职级，修 bug 和写文档测试初级工程师加一个稍微上心的经理就能做到。而且六个月的高级级别工作、还没真正上线的东西，确实不足以晋升。我理解频繁重组很让人沮丧——单凭这一点就足以不去谷歌这类大公司。这才是真正的问题所在。
phamilton查看英文原文
Writing documentation and fixing bugs is in fact not the bar for a senior software engineer. I don't disagree with the promotion committee on that front. IIRC, Senior Software Engineer is a terminal level. You aren't expected to advance any more once you reach that level. Some do, but you can stay a Senior Engineer for the rest of your career and that's fine. So certainly "can fix bugs and write docs and tests" isn't sufficient for that promotion. A junior engineer and a manager who is at least partially paying attention can get that done. I also don't really disagree with the evaluation that 6 months of Senior level work isn't enough for a promotion, especially if nothing actually shipped. I get that constant reorgs are frustrating. That alone is enough of a reason to not work at Google or another BigCo. That's the real problem here.
历次讨论
同类还值得读
用十年时间自学编程（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