职业与工作方法blog.stephenwyattbush.com
无我编程十诫
Dad and The Ten Commandments of Egoless Programming (2012)
2015 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
作者回忆父亲教给他的“无我编程十诫”，其源头是 Jerry Weinberg 1971 年《程序开发心理学》中的理念：批评代码而非批评人、你是代码之外的人、复审的目的是发现问题而非指责个人等。文章在 2015 和 2022 年两度登上 Hacker News 首页。
为什么经久不衰：这些诞生于 50 多年前的原则至今仍切中代码评审与团队协作的要害，提醒每一代程序员放下自我、把代码当作品而非身份。
HN 评论精选
把评审意见改成问句，能让对方自己发现错误而不觉得被指责
一位同事教我把代码评审的每条意见都写成问句：不写“这个循环不会终止”，而写“这个循环会终止吗？”直接指出错误听起来像“你搞砸了”，而提问让人感觉是自己发现了问题并主动修复，而不是被人指责后感到愚蠢和尴尬。这个方法虽微妙，但效果很好。
greggman查看英文原文
> Critique code instead of people – be kind to the coder, not to the code A fellow co-worker taught me by example to try to always phrase each code review comment as a question. Instead of > This loop never terminates Write > Does this loop terminate? Instead of > There's no test for this condition write > Is there supposed to be a test for this condition? I'm probably not thinking of good examples but for some reason, more often than not, the direct comments came across as "you screwed up!" where as the questions instead made it feel like I was discovering my own mistakes rather than have someone tell me I made one. It's probably subtle and maybe some people will think it's dumb but I really appreciated it. It felt like it went a long way toward me feeling like saw my own mistake and fixed it before I checked it in instead of the direct approach which made me feel stupid and embarrassed. I've tried to adopt that approach (though it's a struggle to remember to apply it).
指出十诫源自 Weinberg 1971 年的著作，且历久弥新但常被遗忘
Jerry Weinberg 在 1971 年就写下了这些“诫命”（遗憾的是文章只链接了他的书却没提他的名字）。尽管编程实践发生了巨大变化，这些原则依然适用——但我们程序员总是不断忘记它们，需要周期性地被提醒。
greenyoda查看英文原文
Jerry Weinberg wrote those "commandments" in 1971. (It's sad that the article gives a link to his book but never mentions his name.) It's interesting how well they've kept their relevance over the years, despite the huge changes in the practice of programming. However, we who do the programming still keep on forgetting these things and need to be periodically reminded of them.
“代码被读的次数远多于被写”是值得补充的重要原则
这份清单最妙之处在于稍加改动就能适用于任何领域。我会补充一条：读你代码的时间远多于写它的时间。理解这一点不仅影响写代码的方式，也让人意识到项目正是靠复用清晰封装的库构建起来的——为人类写代码需要一点同理心，而这往往也有助于设计。
danso查看英文原文
The best part of this list is that with some tweaks, the commandments can pretty much apply to any field of personal and professional pursuit. One rule I might add (and one that is also easy to apply elsewhere): Remember that far more time will be spent reading your code than writing it. Grokking this not only has practical implications for how you write code (suddenly, the importance of style guides becomes clearer), but it makes you realize that this is how projects get built: programmers re-using libraries that contain encapsulated, clear functionality. Realizing that someone has to read your code -- even if that someone is mostly just you -- requires a modicum of empathy...and more often than not, this aids in the design process. A common complaint about learning via something like Codecademy is that you might learn the syntax and how to solve problems...but you don't get much guidance on how to apply that knowledge to real projects. I think part of this is because with Codecademy, you're only writing code for the auto-checker to compile and test. Once you start writing code for humans to comprehend and re-use, it becomes easier to see how code becomes a real-world project.
把代码问题当成人身攻击的资深开发者往往难以成长
我完全赞同，其中第二条最有启发：“你不是你的代码。评审的全部意义就是找出问题，问题一定会被找出来，别把发现的问题当成针对你个人。”我职业生涯中遇到过一些资深开发者，一被指出代码问题就大发脾气。多年下来，这些人有个共同点：他们陷入了不断犯错又拒绝从中学习的死循环。
mkl95查看英文原文
I agree with all of it. I find commandment 2 to be the most enlightening one. > You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don’t take it personally when one is uncovered. In my career, I have had to deal with other senior developers who would throw tantrums whenever I pointed out something problematic about their code. Over the years, there's something all those people seem to have in common - they are stuck in an endless loop of making mistakes and refusing to learn from them.
历次讨论
同类还值得读
用十年时间自学编程（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