职业与工作方法jeffknupp.com
“DevOps”如何杀死开发者
How 'DevOps' Is Killing The Developer
2014 — 2018，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章批评 DevOps 实践把运维、数据库等职责压到开发者身上，让开发者被迫成为多面手，削弱专注与专业分工。评论则围绕 DevOps 的真正含义、全栈开发者的角色，以及问题究竟在工具还是管理实施展开争论。
为什么经久不衰：它触及 DevOps 与全栈角色边界、责任归属的长期争议，十多年后仍常被讨论。
HN 评论精选
DevOps 的核心是用开发手段做运维，并非让开发者兼任运维。
DevOps 不是让开发者去干运维。它的背景是自动化吞噬一切，而运维的很大一部分现在就是写代码。DevOps 人员不是既开发又运维的人，而是只做运维、但通过开发来做运维的人。问题不是初创公司对大型企业，而是一个人写程序还是五个人手工干活。
NickPollard查看英文原文
DevOps isn't amount making Developers be Ops guys. It's about the fact that automation eats everything, and a significant part of 'ops' is now coding. A DevOps person isn't someone who develops, and who does Ops. It's someone who does only Ops, but through Development. It's not about start ups vs Enterprise, it's about 1 person writing programs or 5 people doing things by hand.
全栈开发者适合做懂全局的项目负责人，而不是取代所有专家。
市场在成熟。看建筑行业：总承包商什么都会一点但不精，正像全栈开发者。这不是专业化的终结，而是由深入理解全部工作的开发者来主导项目管理。让团队全是全栈开发者很蠢；让全栈开发者当项目负责人、团队里有专家，才是好主意。
maratd查看英文原文
The market is maturing. Take a look at a market that is similarly structured. Look at construction. You have general contractors and then you have subs that work under them. A general contractor is a jack of all trades, master of none. Exactly what a full stack developer is. This isn't the end of specialization. It's the beginning of project management steered by developers who intimately understand all of the work involved, even if they aren't as competent as the specialists. Having a team consist of all full-stack developers is just stupid. Having a full-stack developer as the head on a project, with specialists on the team, is a great idea.
开发者若不了解真实需求和上下文，再努力也可能解决错误的问题。
纯粹的开发者会出问题，因为他们拿不到做好工作所需的信息。我经历过瀑布式流程：分析师、项目负责人层层转交任务，工作按时交付，产品却常失败——不是有 bug，而是没人真正清楚要解决什么。开发者做了很多工作，却用错了方向；然后产品失败，开始互相甩锅。所以我宁愿少写点代码，也要知道自己写的东西真能解决某个人的问题，而不是闭门造车，因为我对用户需求的理解来自传话游戏。
hibikir查看英文原文
Pure developers are a problem because they will the information do their job well. I go back a few years, to an old, waterfall-like job. I was handed work by an analyst, that was handed a task to analyze by an engagement lead, who might at some point talk to someone using the application. The work was always handed out on time, but the product often failed, not because it was buggy, but because nobody actually had much of an idea of what we were really trying to solve. So us developers got much work done, but the work didn't actually solve real problems: The force is applied to the wrong vector. Then the product fails, and the blame game begins: Changes are too expensive, because the developers didn't know what the real invariants are. Queries are slow, because the database architect wasn't told about the questions that the database had to answer. The business analysis just wrote documents. It was all a big catastrophe. That company moved to Scrum, the terrible way: Here, have this self organizing team full of specialists that don't know anything outside of their domain. They are still failing to this day, but now they blame each other in retrospectives. So I'd much rather be stuck coding less, but then being aware that my code is actually solving a problem for someone, than just writing castles in the sky, because everything I've been told about what my userbase needs comes from a game of telephone.
DevOps 的本意是让构建者对可运维性负责，问题在于公司文化而非概念本身。
作者没理解 DevOps（很多公司也没理解）。DevOps 不是把开发者拉去值班，而是在软件设计早期就考虑运维问题，并承认：构建者也要对软件是否易于运维负责，软件上线后才会表现更好。把有毒的公司文化归咎于 DevOps 或全栈，太容易了。
jupp0r查看英文原文
The author didn't get DevOps (so don't many companies). It's not about putting developers on-call, it's about taking operational concerns into account early in the design of a piece of software and acknowledging that it's going to do much better in the wild when the people building it are also accountable to making it easy to operate. Blaming DevOps (or full-stack, for that matter) for a toxic company culture is just too easy.
历次讨论
同类还值得读
用十年时间自学编程（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