职业与工作方法zef.me
我讨厌解谜：我还算程序员吗？
I Hate Puzzles: Am I Still a Programmer? (2011)
2014 — 2016，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇 2011 年的文章从作者讨厌解谜、怀疑自己是否还算程序员说起，讨论程序员是否必须“有解谜头脑”。评论区有人认为程序员只是职业身份，也有人引用 Dijkstra 和工程实践，强调清晰系统思维与理解真实问题比解谜技巧更重要。
为什么经久不衰：它触及程序员身份认同和算法面试文化，多年后仍能引发共鸣。
HN 评论精选
程序员由是否编程定义，不是某种人格或智力标签。
我已经编程 18 年了。那么恭喜你，你就是程序员！不管那些推销各种“成功学”的人怎么说，“程序员”不是一种人格类型，而是一份工作描述。只要你编程，你就是程序员，就这么简单，句号。别让任何人说服你相反。
smacktoward查看英文原文
> I’ve been programming for 18 years now. Then congratulations, you are a programmer! Despite what you'll hear from people peddling various flavors of Kool-Aid, "programmer" isn't a personality type. It's a job description. If you program, you are a programmer, end of line, full stop. Don't let anyone convince you otherwise.
程序员偏好多样；软件工程师重交付与维护，计算机科学家重算法优化，不爱解谜也能是好程序员。
绝对是的！每个人偏好不同。像你一样，我对谜题几分钟就失去兴趣；别人从找到缺失拼图块中获得满足，我没有。我不能替你的经历说话，但对我来说，我喜欢架构，喜欢找到正确方式把部件粘合起来，也喜欢调试和汇编优化。我发现这对应典型软件工程师和计算机科学家的区别：工程师关心高效完成事情，不只算 CPU 周期，还要考虑编码时间、培训新人、维护、可扩展性和代码运行频率；计算机科学家则追求高效解，喜欢拆解算法。
karl_gluck查看英文原文
Definitively: Yes! Everyone has their own preferences. Like you, I lose interest in puzzles after a few minutes. Whatever it is that gives some people great satisfaction out of finding that one missing piece, I didn't get it. I can't speak to your experience, but for me, I like architecture. Finding the right way to glue pieces together is actually very interesting to me. I basically implemented reflection in C++ before I even knew that's what it's called because I thought it would be fun. I enjoy debugging and assembly optimizations. What I found is that this speaks to the difference between a prototypical Software Engineer and Computer Scientist. Engineers are interested in getting stuff done efficiently, and not just in CPU cycles--time for coding, training new coders, maintenance, extensibility, and how often the code will ever be run all must be taken into account. In my experience, grabbing someone else's solution via a package manager or using a 10-minute brute-force solution to a very hard problem can be the most "efficient". Just throw comments on it and avoid the puzzle so you can get something working. Of course, be sure to isolate the code so that if it ends up being a hotspot it's easy to fix later. Computer Scientists, on the other hand, seek that efficient solution. Many of the PhD candidates I encountered were optimizing very specific cases of very hard problems (largely related to distributed computing). They enjoy spending time picking apart algorithms and understanding the problem so thoroughly that they can prove, confidently, that they have the most efficient solution to any given problem. In the end, each broad category relies on its partner, and all programmers have to have some of both. Some of us just lean harder to one side than the other.
Dijkstra 认为清晰系统思维比解谜技巧更重要。
Dijkstra 多次评论过这一点。他说：“我仍常听到成功程序员应该‘有解谜头脑’，而我觉得清晰系统的头脑更关键。现代合格程序员不应以解谜为乐，不应沉溺于技巧，应保持谦逊，像躲避瘟疫一样避免取巧方案。”
maxlybbert查看英文原文
Dijkstra commented on this multiple times (e.g., https://www.google.com/search?q=dijkstra+puzzle+minded+ewd+site:cs.utexas.edu ). "I still often hear that a successful programmer should be 'puzzle-minded' whereas I have the feeling that a clear and systematic mind is more essential. A modern, competent programmer should not be puzzle-minded, he should not revel in tricks, he should be humble and avoid clever solutions like the plague" ( https://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD303.html ).
真实问题解决靠理解情境与历史，不是猜出题人的技巧。
我也讨厌谜题，一直不明白为什么那么多程序员觉得它们有趣。我认为现实世界的问题解决很大程度上是理解：理解情境、问题的历史、尝试过什么、什么没奏效，问很多问题并分析答案。这才该叫问题解决，而它与解谜重叠很少。解谜通常是找出题者用的那个窍门，面试时则是把解法套进出题者设想；现实问题不是这样运作的。
lukaslalinsky查看英文原文
I also hate puzzles and I never understood why so many programmers find them interesting. I think much of real-world problem solving is about understanding. Understanding the situation. Understanding the history of the problem, what has been tried, what didn't work, etc. Asking a lot of questions and analyzing the answers. That's what I think should be called problem solving and I think there is very little overlap between this and puzzle solving. Puzzle solving is generally about finding the trick that the creator of the puzzle used, or in the case of job interviews, fitting your solution to what the creator imagined. Real-world problems don't work like that.
历次讨论
同类还值得读
用十年时间自学编程（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