职业与工作方法defmacro.org编辑精选
工程管理经验教训（2014）
Engineering management lessons (2014)
2014 — 2017，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 defmacro.org 2014 年的一篇工程管理经验总结，作者基于五年管理实践，列出了工程经理应该做和不该做的事情，涵盖招聘、授权、代码参与、团队责任等话题。文章在 2014 和 2017 年两次登上 Hacker News 首页，引发了关于管理者是否应该写代码的长期争论。
为什么经久不衰：工程管理的核心难题——管理者要不要写代码、如何保护工程师注意力、如何招聘——至今没有标准答案，这篇经过时间检验的经验清单仍是新任管理者的良好起点。
HN 评论精选
管理者停止写代码后会遗忘软件开发的痛苦，失去技术判断力和仲裁分歧的资格
我和许多人一样有同感：文中大部分建议不错，但“工程管理者不应直接做技术贡献”这条是错的。尤其不合理的是，当你不再动手写代码，就很难在团队出现尖锐技术分歧时充当“仲裁者”——作为非贡献者，你只能依赖别人告诉你的信息，而不是自己的工程判断。我的反对意见其实更深：软件太难了，就像分娩一样，我们有一种压倒性的遗忘痛苦的偏见。一旦你停止写软件，你就开始改写自己的历史——在你记忆里一切都直截了当、总能按时交付。于是你走上了一条不归路：无法理解为什么这东西要这么久，为什么你们就不能把 bug 修完？我亲眼见过一位极有技术天赋的人转入管理、完全停止写代码后，以惊人的速度忘记了十多年的痛苦经验，忘记了软件的无限复杂性。
bcantrill查看英文原文
I had the same reaction to this as many others have, in that I think much of this stuff is good/fine, but the advice that engineering leadership shouldn't actually directly contribute in a technical fashion is wrongheaded. I have elaborated on this in the past[1], but in particular, I don't think it's reasonable to expect to be the "tie breaker" in what is (tautologically) a sharp divide on an engineering team when you no longer contribute: as a non-contributor, you will be relying on what people are telling you instead of your own engineering judgement. But my objection to the advice that management should not contribute technically is actually deeper than technical conflict resolution. Software is so hard that it becomes like child birth in that we have an overwhelming bias to forget the pain: the second you stop writing software, you start rewriting your own history. So as far as you can remember, it was all pretty straightforward, you always hit your deadlines, etc. And with this, you have started down the primrose path in which you just can't understand why this is taking so long and can't you guys just get all of the bugs fixed?! I (like many -- if not most -- software engineers) have seen this first hand: one of the most technical people I've ever worked with ventured into management, stopped writing software entirely, and -- with astonishingly short latency -- forgot over a decade of experience of pain. He forgot the inifinite complexity of software, and instead assumed that bugs were due to a lack of urgency, laziness, or worse. At one point, we were getting crushed by a very nasty issue, and he called a meeting to spend an hour telling us how important it was (oh, thanks!) and that he "didn't want to hear details; just get it fixed". If he had only asked "what I can do to help?", I was ready with: "You are -- or at least were -- a damned good engineer; you can help us debug it." This brings me to a slightly broader point: as technical leadership, I believe that direct contribution is essential, but you do need to be very careful about how you contribute. The last thing you want is to be on the critical path of some feature and have the team blocked because you've been called into a board meeting (or a customer visit or an off-site or a planning meeting or any of the other of zillions of ways in which organizational leadership must spend some portion of their time). For me personally, the answer this is particularly easy because it dovetails with what I love to do anyway: my way of directly contributing to my team is to debug. By picking up bugs that no one else is looking at, you're out of the critical path, but you are helping the team, staying technically current, and reminding yourself -- constantly! -- of the brutal complexity of software engineering. [1] http://www.slideshare.net/bcantrill/surge2013 video: http://www.youtube.com/watch?v=bGkVM1B5NuI
从失败视角补充：管理者最大的失败是不懂下属工作、失去信任、不培养下属、不给方向
我认为“不该做”的部分太具体也太短了，而且从失败中学到的东西比从成功中学到的多得多（我可能对此有偏见，我的管理经验来自大型官僚机构）。以下是我总结的技术管理者失败的主要方式：1. 你不了解下属的工作，分不清好坏——这意味着“不要写代码”并非放之四海皆准的建议；2. 人们不信任你，可能不是因为你做了什么，而是因为你没做的事，比如定期交流、及时传递坏消息；3. 你不为下属的职业发展着想，让他们感觉你在帮助他们成功——这对典型的“厌恶自我推销”的工程师性格尤其重要；4. 你不设定目标和方向——细节是工程师的事，你的工作是给出清晰的整体方向并帮助团队坚持它；5. 你忘了自己的成功可能并非源于你的管理。
drblast查看英文原文
I think the don't section is far too specific and short. I also think you can learn a lot more from failure than success, but I might be biased there. My management experience is in large bureaucracies. Here are my top ways to fail as a technical manager: 1. You don't understand what the people who work for you do well enough to know good work from bad work. This has all sorts of bad ramifications. You can't be a leader if you don't understand what's going on. Does that mean you should be able to write code? Maybe. . .it depends on the job. It does mean that "Don't write code" is not universally good advice. 2. People don't trust you. This might not be because of anything you've done but things you've failed to do, like chat with people regularly and give them bad news quickly. 3. You don't manage the careers of subordinates so that they feel like you're helping them succeed. This is particularly important for the typical engineering personality type that finds "selling yourself" repulsive. Don't have enough data to "sell" a subordinate at review time? See #1. 4. You don't set a goal or direction. Details are the engineers' job. You have to know about the details and understand them, but your job is to give a clear overall direction and goal and help the team stick to it, and change it when necessary. If you've hired good people who want to accomplish something, they'll do that. Just make it clear what that is. 5. You forget that your success might occur in spite of you. Especially as a middle manager, you're like an insurance company; if there's anyone on your team that causes that team to be a success, you look like a success. A mostly dysfunctional team (or a completely dysfunctional manager) may still succeed. Understand that great people risk a lot more working for you than you risk having them work for you. If you're successful, you should live in fear that you're doing everything wrong and constantly check yourself. You also need to hide this fear from everyone. 6. You don't live to serve. Your goal every day should be to give your people the tools they need to succeed.
管理者的核心职责是充当防火墙，保护工程师注意力不被会议和干扰侵蚀
刚花了几个星期攻克一个相当难的工程问题（此前做了很久的“架构”工作），我一定要在“该做”清单里加一条：保护工程师的注意力。作为管理者，你是干扰世界与干成事情的世界之间的主要防火墙。如今大多数地方已经把一定程度的干扰制度化——各种例会——但除此之外，管理者必须能在工程师攻克难题时保护他们不受干扰。另外，文中说“招聘解雇由你决定，团队发生的一切都是你的责任”——委婉地说，在大型组织里这并不完全成立。
biztos查看英文原文
Having just spent a couple weeks on a pretty hard engineering problem, after having done more "architecture" stuff for quite a while, I would definitely add one thing to the Do's: * Protect your engineers' attention. As a manager you are the primary firewall between the world of distraction and the world of getting shit done. Most places these days have institutionalized some amount of distraction -- the various recurring "ceremonies" -- but anything beyond that, it's essential that the manager can protect the engineers from being distracted when they're working on hard problems. (I've been pretty lucky in this regard throughout my career, but now that part of my job is to live among the distractions it's really been driven home.) Also: > You’re the one who makes hiring and firing decisions. Everything that happens on your team is your responsibility. This is, to put it gently, not quite true in larger organizations.
对专业工程师而言，授权式管理最有效：允许无责认错并让团队共同学习
道理很简单：工程师是专业人士。专业人士会犯错，但在允许他们无后果地承认错误并从中学习时最为高效。在一个好的软件团队里，某个开发者的“大错误”会被整个团队修复，我保证全队没人会再犯同样的错误，也不会对犯错者心存芥蒂——除非成了惯犯。总之在这种环境里，授权是最有效的领导方式。它并非适用于所有员工（比如需要更多手把手指导的新人），但对工程师这样的专业工作者，这几乎是唯一可行的方式——尤其当资深技术人员的经验比经理多几十年时。
exelius查看英文原文
It's pretty simple: engineers are professionals. Professionals make mistakes, but are most effective when allowed to own up to them without consequences and learn from them. In a good software team, a single developer's "big mistake" gets fixed by the whole team. I guarantee nobody on that entire team will make that same mistake; nor will they hold anything against the offending developer unless there's a pattern. But in short, empowerment is the most effective leadership style in this environment. It's not appropriate for all employees (specifically newer folks who need a bit more hand-holding at first) but for professional workers like engineers, it's really the only way to go -- especially if you have senior technical employees who have decades more experience than their manager.
历次讨论
同类还值得读
用十年时间自学编程（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