职业与工作方法danluu.com编辑精选
完全离谱的做法是如何变得正常的
How Completely Messed Up Practices Become Normal
2015 — 2025，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
Dan Luu 的这篇文章探讨为什么糟糕的工程实践（如从不跑测试、极低的系统可用性）在公司里被普遍接受甚至视为正常。作者通过多个匿名案例指出，即使是号称工程文化优秀的公司，也常常把功能交付置于可靠性之上，而身处其中的人逐渐对荒谬现状麻木。
为什么经久不衰：它揭示的组织惰性与“劣习正常化”问题跨越十年依然普遍存在，对任何想理解或改变公司工程文化的开发者都有共鸣。
HN 评论精选
用“猴子实验”类比劣习的代际传递，但指出该实验其实是讹传
我立刻想到“五只猴子和梯子”的心理学实验：第一只猴子爬梯子拿香蕉时所有猴子都被水喷，之后新来的猴子一爬梯子就会被老猴子攻击，不断替换猴子，最后没有一只猴子知道梯子的规矩是什么，却依然没有猴子敢爬。这个故事在开发/产品圈很流行，但多查了一下， apparently 它是虚构的。
danso查看英文原文
I immediately thought of the "5 monkeys and a ladder" psychology study, in which the first monkey attempts to climb the ladder to get a banana and all of the monkeys are sprayed with water. Then one of the monkeys is replaced with a newcomer, who then tries to climb the ladder, but this time, the remaining original monkeys attack it. And so the replacing of the monkeys continues, until none of the monkeys knows what the deal with the ladder is and yet none attempt to climb it. This is a popular story in dev/product culture but after a little more Googling, apparently it's apocryphal: https://www.psychologytoday.com/blog/games-primates-play/201203/what-monkeys-can-teach-us-about-human-behavior-facts-fiction
认为与其对抗组织，不如接受现实或换工作
作者抱怨的大多数问题，归根结底是业务需求比工程团队的需求更重要。直白地说：他们付钱让你干活，不是让你改善组织——那是请领导层来做的。想参与领导层，就往上爬或自己创业。当我学会不再费力去修那些超出我能力范围的东西后，日子好过多了。不喜欢你的经理、文化或业务，就换个地方工作，就这么简单；做不到，就得学会妥协。
vinceguidry查看英文原文
Most of what the author is complaining about boils down to business needs being more important than the needs of the engineering team. To be blunt, they're paying you to do a job, not to make the organization better. That's what they pay the leadership for. You want to be part of the leadership, work your way through the ranks or start your own business. My life got much, much easier once I learned to stop straining so hard to fix things that are bigger than me. If you don't like your managers, or the culture, or the business, find another place to work, it's that simple. If you can't do that, you're simply going to have to learn how to compromise.
反驳文章的因果论：不交付功能的公司同样可能运维极差
文章有个隐含的虚假二分法：公司只重视功能增长，因此直接导致运维表现差。但你可以几个月不交付任何功能却依然可用性糟糕。两个 9 的可用性？我一半的客户要是能有一个 9 就欣喜若狂了——那些地方开发者处处受限，半年到一年才发布一次。这就是我作为顾问接触的大多数企业客户的常态：他们几乎无法执行任何重要的事，客户忍受他们只是因为别无选择（healthcare.gov 只是被曝光的例子）。
devonkim查看英文原文
There seems to be a bit of a false dichotomy underpinning this article that companies value feature growth above all else and this directly results in poor operational performance. However, you can get terrible availability without delivering any features whatsoever for months and months. Two 9s of availability? Half the customers I've had would be ecstatic to have even ONE 9 of availability. And those guys hardly ever ship any code due to how encumbered developers typically are in those places and release maybe once every 6 months to a year perhaps. In fact, this is basically my typical experience with most enterprise customers I've worked with as a consultant - they're unable to execute almost anything materially important and customers put up with them because nobody else is in that niche enterprise market that's keeping people employed by lack of choice / market consolidation (healthcare.gov is just a visible example - plenty more projects are even worse with perhaps even larger budgets with zero media attention).
指出大公司的劣习源于组织惰性和管理层与技术脱节，而非增长压力
不只是追求增长的新公司，老牌大公司也有一模一样的问题，但原因不是忽视最佳实践，而是惰性无处不在：一切自上而下执行、没有反馈渠道，人们在乎年终奖，不愿向上级提出难听的真相。最关键的是管理层里没有一个懂技术的——基层懂技术的人与直属上级之间存在完全的心智断层。这些公司于是花大钱请外部顾问，顾问照本宣科给出显而易见的方案，再通过下一轮重组自上而下推行。我们公司高层刚发现 DevOps 和敏捷，现在人人都被要求做 DevOps，但自上而下的沟通方式一点没变，那效果肯定“棒极了”。
iSnow查看英文原文
It's not just growth-oriented new companies. The old ACME BigCorp.'s have exactly the same problems, but not because they disregard best practices because everyone is fixated on growth, but because inertia has crept in everywhere. Because everything is executed top-down and there's no back-channel. Because people care about their yearly bonuses and would rather not bring up uncomfortable truth to their superiors. And most of all, because there are zero techies among managers. There's a complete mental disconnect between the tech-savvy among the grunts and even their direct reports, let alone more senior management. Those companies then pay big money for external consultants to tell them how to fix issues; the consultants tell them the obvious solutions from their books (which may or may not overlap with what the grunts would have told them), and then those solutions are pushed down in the next restructuring. Where I work, senior management has just discovered DevOps & Agile, and now everyone has been told to do DevOps, but without breaking up the top-down communication style. That's going to work just wonderfully.
改变组织的前提是先建立个人信誉
WTF 时刻出现在你还没有信誉的时候。你会想听一个提交历史空白、还用错术语的陌生人告诉你怎么干你的工作吗？先证明你有能力在现有体系内工作，再开始你的变革运动。
closeparen查看英文原文
The WTF moments come when you don’t yet have credibility. Would you want to hear a stranger with an empty commit history use the wrong keywords to tell you how to do your job? Start your campaign to change a place after demonstrating ability to work within it.
认同文章，引用“构建坏了对大家都公平”的荒诞案例
这是我读过最好的公司文化文章之一。“我没能让大家在提交代码前跑一次构建，更别说跑测试了，所以构建每天坏好几次。我提到这影响生产力时，被告知没关系，因为对每个人都一样。”我笑死了。我有个朋友就在这样的公司工作，他讲的公司轶事简直像情景喜剧。
luord查看英文原文
This is one of the best articles on company culture I've read. > I lost the fight to get people to run a build, let alone run tests, before checking in, so the build is broken multiple times per day. When I mentioned that I thought this was a problem for our productivity, I was told that it's fine because it affects everyone equally. I laughed so hard. One of my friends works in such a company and I've lost count of how many times I've told him that his accounts of their exploits read like sitcom scenes.
历次讨论
同类还值得读
用十年时间自学编程（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