职业与工作方法kalzumeus.com编辑精选
不要自称程序员
Don't Call Yourself a Programmer
2011 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇经典职业建议文章劝软件工程师不要把自己局限在“程序员”这个标签上，而要从公司业务角度说明自己创造的价值；文中讨论了成本中心与利润中心、头衔、求职与职业选择，也顺带批评了学术界的价值评估方式。作者的核心意思是：技术能力要转化为雇主和客户能理解的商业价值。
为什么经久不衰：它把技术人的职业焦虑转成可操作的商业价值视角，隔了多年仍在求职定位、头衔和职业选择上适用。
HN 评论精选
做无聊的企业 CRUD 工作也能创造可量化价值，并与创业经历交替形成满意职业。
我很喜欢企业里那种无聊、“消磨灵魂”的工作。为什么？因为我可以坐下来，一天内做出一个带简单审批流程的基础 CRUD 表单。它一年能为公司省下 10 万美元，客户喜欢我；而且因为它足够简单，通常不需要维护，也许一年才更新一次字段。到周末，我已经为公司省下超过我工资的钱；一年后，我成了公司的关键资产。三年后，我把一切都优化完了，ROI 增长放缓，我就离开。这种模式不是悲剧，也不会消磨灵魂；它让你在商业世界成为抢手货，每几年就有机会改变自己的生活。我通常这样干三年，再去创业公司干两年。它给我的经验和技能比只待在一类公司的人宽广得多，也让我在大行业（银行、能源等）积累多年经验，再用这些经验找到适合创业公司解决的真实问题。这样做快 20 年，我拥有非常满意的职业生涯。
synnik查看英文原文
I love corporate, boring, "soul-crushing" work. Why? Because I can sit down, whip out a basic CRUD form with a small approval cycle in a day. It saves a company 100K over the year, I am loved by the customers, and because it is so simple, it normally requires no maintenance. Maybe we update the fields once a year or so. At the end of the week, I've already saved the company more than my salary. After a year, I am a critical asset to the company. After 3 years, I've optimized everything, the ROI slows down, and I move on. This pattern is not a tragedy. It doesn't crush your soul. It makes you a prized commodity in the business world, with a chance to make a change in your life every few years. I have usually alternated between 3 years doing this, then 2 years doing startup work. It has given me a much broader base of experience and skill than anyone who stick to one one side of the coin. It also has given me years of experience in large industries (banking, energy, etc.) which I then use to find very real problems to which a startup can be applied. I have led a very satisfying career, doing this for almost 20 years now.
招聘现实仍看重既有技术栈，与文中“换语言很快”的说法有差距。
现实中技术人员的招聘（不幸地）不是这样。招聘经理最先看的似乎就是候选人用的技术栈。你会以为只有不懂行的招聘人员才这样想，但我的经验是，一些受人尊敬且成功的企业家也按这种思路行事。我不清楚他们的成功与这种思路是相关还是无关。往好处想，创业公司常常需要快速推进，而让人熟悉一个不熟悉的新技术栈所需的那几周到几个月，可能就是没有的。
arbuge查看英文原文
> Do Java programmers make more money than .NET programmers? Anyone describing themselves as either a Java programmer or .NET programmer has already lost, because a) they’re a programmer (you’re not, see above) and b) they’re making themselves non-hireable for most programming jobs. In the real world, picking up a new language takes a few weeks of effort and after 6 to 12 months nobody will ever notice you haven’t been doing that one for your entire career. In the real world this is (unfortunately) not how technical people are hired. The stack they are using seems to be the first thing hiring managers look at. You would think it would be only clueless recruiters who would think this way, but my experience is that well-respected and successful entrepreneurs also operate along these lines. It is not clear to me whether their success is related to or in spite of this way of thinking. To give them the benefit of the doubt, startups often need to move quickly and those few weeks-months needed for people to become familiar with a new stack they're unfamiliar with may simply not be available.
求职应聚焦少数公司并直接说明价值，早期优先选团队和学习速度而非大品牌。
这对早期软件工程师是极好的实用建议。基于我看到的常见误区，再补充几点：不要一次性申请 50 多家公司、指望只有一定比例会回你。选大约 5 家，认真研究其业务，给关键人物写一段话说明你能为他们的业务做什么；失败后再选下 5 家，依此类推。其他条件相当时，选团队而不是选公司。例如，在一家不知名但成长中的公司做核心技术或面向客户的团队，比在 Google 做某个内部工具团队好得多。FAANG 的品牌对未来的招聘者和 VC 有一些价值，但职业生涯早期你真正应该优化的是学习速度。
amirathi查看英文原文
This is fantastic practical advice for software engineers early in their career. Here's some more based on the common pitfalls I see, - Don't apply to 50+ companies at one go thinking only a % of them will call you. Choose ~5 companies, do a lot of homework about their business & write to key people at these places telling in ONE paragraph what you can do for their business. If it fails, choose next ~5 and so on. - Other things being equal choose team over company. E.g. working at core technology or customer facing team at a less-known growing business is much better than working at some internal tools team in Google. FAANG carries some brand value for future recruiters, VCs but you should really optimize learning rate early in your career.
成本/利润中心标签常取决于业务依赖关系和高管认知，不一定反映真实价值。
关于利润中心与成本中心：几年前我所在的团队维护一个 SaaS 应用，它处于某种奇怪的“成本中心/利润中心”叠加态。公司名义上销售这个应用并赚钱，但只要买家愿意为与它集成的旗舰业务服务付大钱，公司往往几乎免费送出这个应用（可以类比带微交易的免费手游）。客户主要通过我们的应用来使用旗舰服务并产生微交易收入；但因为客户真正付费的不是这个应用，高管们始终难以决定把它当成本中心还是利润中心。应用运行良好、大家满意时，高管认定它是成本中心并看低它；应用出问题、客户愤怒并威胁转投别家时，高管才突然意识到没有这个 SaaS 应用就卖不出更多旗舰服务。总之，这段经历在很多方面都古怪又令人沮丧。
chasingthewind查看英文原文
Re: Profit Centers vs Cost Centers I was once on a team that maintained a SaaS application that was in some sort of bizarre super-position of "cost center" and "profit center" a few years back. The company technically sold the app and made money from it, but they also tended to give it away almost for free as long as the buyer was going to be paying lots of money for the company's $FLAGSHIP_BUSINESS_SERVICE that integrated with the app. (Think of it like a free mobile game with micro-transactions.) The primary way customers interacted with $FLAGSHIP_BUSINESS_SERVICE (and generated micro-transaction revenue) was through our application. However because the application wasn't what the customer was actually paying for, the executives had an impossible time deciding whether to treat the app like a cost or a profit center. Whenever the app was working fine and everybody was happy the executives were convinced it was a cost center and looked down on it. Whenever it wasn't working fine and companies began to get angry and threaten to take their business elsewhere suddenly the executives would realize that without the SaaS application they wouldn't be able to sell more $FLAGSHIP_BUSINESS_SERVICE. Long story short, it was a strange and frustrating experience in many ways.
历次讨论
同类还值得读
用十年时间自学编程（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编辑精选创作者的日程与经理的日程
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我们只招最时髦的人
We only hire the trendiest
Dan Luu 在这篇文章中批评科技公司招聘时盲目追逐流行趋势：只招用最新框架、有知名大厂或名校背景的人，而忽视真正有能力的候选人。
职业与工作方法上首页 4 次 · 2016–2021danluu.com