职业与工作方法jsomers.net
速度很重要：为什么快速工作比看起来更重要
Speed matters: Why working quickly is more important than it seems (2015)
2015 — 2025，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇博文讨论“做得快”为什么比直觉中更重要：快速完成能降低开始做事的心理成本、对抗惰性，并带来更多练习和机会。评论区则补充了边界：速度不能替代交付质量，要区分任务风险，并计算延迟的经济代价。
为什么经久不衰：它触及一个反直觉但持久的工作方法原则：速度常被低估；而评论区关于成本延迟、任务风险和慢工出细活的讨论，让这个主题今天仍值得读。
HN 评论精选
速度不如交付质量和可靠性，很多“紧急”问题会自行消失。
40岁。速度没有你交付什么那么重要。首先，人们不知道一件事要花多久；其次，他们会忘记花了多久，但不会忘记做得多好。快速回邮件简直疯狂，我记不清多少紧急问题后来自己解决了：15分钟后就回复“没事了，找到了”。我属于“慢即顺，顺即快”阵营。
koonsolo查看英文原文
40 year old here. Speed doesn't matter as much as WHAT you deliver. First of all, people do not know how much time something takes. And secondly, they will forget how much time it took, but not how well it was made. Responding fast to emails is just crazy. I lost count on how many urgent problems got resolved automatically. "Hey can you help me with this". 15 minutes later "Nevermind, found it". I'm in the "Slow is smooth, smooth is fast" camp. https://www.lesswrong.com/posts/4FZfzqMtwQZES3eqN/slow-is-smooth-and-smooth-is-fast
应拒绝无意义的紧急，只在真实价值和竞争窗口出现时加速。
做软件多年后，我让自己有能力说不。只为紧急而紧急、源于业务绝望或直觉的，我不理。若功能真能带来业务价值，且公司能论证为何昨天就要，我愿意用2到3个月超速透支身心。很多业务匆忙是希望奇迹，而不是审视基本面；基础扎实的公司很少依赖速度，而靠质量和价值。偶尔竞品压力下确实需要快，那才是好理由。
ThalesX查看英文原文
For me, after years producing software, I've set myself up to be able to say no. I disregard urgency when it exists for urgency's sake, coming out of business despair or a gut feeling. I will gladly work for 2 - 3 months on hyper mode, giving away my mental and physical health for a feature that will actually provide business value and for which the business can make a good case for why it's needed yesterday. Working with multiple companies on executive and / or consulting levels, I feel like a lot of business rush is done because business 'needs it now' in the hope that it will improve the bottom line because it's easier to expect a miracle than it is to take a good look at your fundamentals. The businesses with the most solid foundation I find are the ones that rarely need to rely on speed and instead rely on quality and produced value... once in awhile, a feature idea comes up that can propel the company - especially in the face of competitors - and it needs to be done as fast so that the producer can get as much value out of it before the competition catches up. That's a good reason to expect speed. Today's society expects hyper growth, hyper speed, hyper scale, but that is because this is what is mostly advertised and we as humans have a tendency to expect the world to work as is advertised, when in reality, there are a lot of smaller companies that don't create anxiety filled working days for their employees.
用延迟成本和期权价值说明，早发布能最大化经济收益。
Don Reinertsen 用经济论证支持这个观点，谈到期权价值和延迟成本。延迟成本正是“快为什么重要”的经济理由：早发布能最大化产品在市场上有用的经济寿命；比对手早发布，就能在对方追上之前收溢价，之后价值会下降。早3个月发布就多3个月最赚钱的收入；若为改进而延迟3个月，就要算改进成本加上错过早期收入的代价。
jillesvangurp查看英文原文
Don Reinertsen has been making this point and uses economical arguments to back it up: https://www.youtube.com/watch?v=L6v6W7jkwok&list=FL6P7ZzM6GT554-6xA_3lvjg&index=3&t=5s I love this presentation because it adds strong economic arguments to a lot of practices that are quite common in software engineering but typically lack good argumentation as to why they are good. He covers a lot more ground in this presentation. Well worth your time if you are involved in any way in planning software development. I love his notions of option value and cost of delay. Cost of delay is exactly the economic argument why working quickly is important. Once you get it, is obvious that you should do agile, release early, and avoid embarking on long/uncertain refactoring/redesign efforts unless you can justify the payoff. In short, any development that ships early maximizes the useful economic life on the market. If you ship something new earlier than your competitors, you get to charge a premium until they catch up. At some point your new thing becomes a commonality and the value drops. In some case, OSS just gobbles it up and the value becomes 0$. So shipping 3 months earlier means you get to earn revenue for 3 months extra when it is still most lucrative. If you instead delay for 3 months because you are doing some thing that make things better in some way, you have to consider the cost of doing that AND the cost of missing out on that early revenue. Don Reinertsen suggests you simply do the math consider the cost of delay when e.g. deciding on a big refactor vs. a lets get this to market ASAP type strategy. You don't even have to do a particularly good job at doing the math to out-compete gut feelings here.
速度不能牺牲效率和长期可维护性，要平衡即时产出与未来成本。
效率也比看起来重要。你可以有很多低质量、半成品式的产出。我们事前花多少心思决定要做什么？有些项目和想法不值得投入。编程中还常走捷径，结果以后花更多时间：缺文档、不可复现、代码质量差。我在学术界看到很多工作牺牲效率，换草率的即时方案。需要平衡，并考虑一个月或一年后会发生什么。
danielecook查看英文原文
Efficiency is also more important than it seems. You can have lots of low quality, half-baked output. How much forethought do we put into what we will work on to begin with? Some projects and ideas are not worth the effort. Or an alternative solution to a problem is preferable over one you’ve been hammering away at for days, and would be easier to implement. And in the realm of programming, it’s often easy to take shortcuts even though later on they wind up costing more time for you or others involved: omitting documentation, not making something reproducible, poor code quality, etc. Having spent most of my career in academia I see a lot of the work makes this trade off: efficiency is sacrificed for a sloppy, immediate “speedy” solution. You need to find a balance and think through problems, considering not only what is immediately in front of you but also what you’ll be doing in a month or year. Otherwise you’ll wind up with a project or codebase that begins to drag your productivity and output with it.
历次讨论
同类还值得读
用十年时间自学编程（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