职业与工作方法sites.google.com编辑精选
练习编程（2005）
Practicing Programming (2005)
2012 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
Steve Yegge 2005 年的文章讨论程序员如何像音乐家一样进行刻意练习：主动尝试新东西、保持紧密的反馈循环、做小项目，并持续更新技能以免被淘汰。文章强调练习要直接针对有挑战的核心问题，也引出了日常工作是否算练习、底层基础知识是否仍然重要等讨论。
为什么经久不衰：它把“经验年限”拉回到“练习质量”这个根本问题，方法朴素且不依赖具体技术栈，所以十几年后仍能指导开发者规划成长。
HN 评论精选
练习应快速验证核心想法，避免在周边基础设施上浪费时间。
我认为编程练习应该围绕两点：1）尝试许多新东西；2）在非常紧凑的反馈循环里做。所以可以写小点子，但一定要直接从问题的核心开始——不要先做注册/登录流程，也不要先搭新 API，而是直接进入新颖、有挑战、有风险的部分。这样当想法失败时，你才不会把时间浪费在为它搭建支撑设施上。另外，探索性编程要选轻便灵活的工具，比如动态语言、REPL 等。
ntoshev查看英文原文
I think practicing programming should be about: 1. trying many new things 2. in a very tight feedback loop So, code little ideas, but make sure you start from the essence of the problem - not the registration/login process, not the new API - start directly from the part that's new and challenging and risky. In this way, when the idea fails, you wouldn't have wasted time building support infrastructure for it. Also, pick light and flexible tools for exploratory programming - dynamic languages, REPL, etc.
日常工作本身就是练习，拿职业运动员做类比并不完全成立。
有道理，保持技术更新、别被淘汰，当然。但我不太认同这个比喻。程序员每天都在实践；如果你工作中在写代码，那就是在练习。更关键的是：如果作者在 NFL 打球，他会希望角卫在比赛时表现出色、每天训练，当然，还要晚上回家继续练习成为四分卫和教练，因为得跟上时代。我猜 NFL 里并不是这样。
vega查看英文原文
So, fair point. Keep up to date with technology, don’t become obsolete. Sure. But I don't know about the metaphor. I mean, programmers do practice daily. If you’re coding at work you’re practicing. More to the point: if the author played in the NFL he’d want the cornerback to do exceptionally well at game time, to practice daily, of course, AND to go home at night and keep practicing to become a quarterback AND a coach because, you know, got to keep up. My guess is that’s not what happens in the NFL.
初学者面临现实权衡：用熟悉技术做出成果，还是花有限时间冒险学新技术。
这是好建议，但不太容易落地。一个人怎么知道什么时候该用已有技能做东西，什么时候该花时间学新东西再用它做东西（可能因为不熟而失败，也肯定更耗时）？对我来说最大投资是时间……他给了一些小项目点子，但最终你确实得用一门技术才能掌握它（他也这么说）。我是一个小团队里的初级程序员，短期内不会招人，所以他建议的很多事都做不了。我幸运地跨栈学了不少，但我们主要语言是 Perl，已经不算最有市场价值的语言了。我有个有用小网站的想法——能写进简历，但不觉得能赚大钱。我是用主要优势、熟悉的技术（Perl 和 SQL）来写，还是选可能兴起的技术（Node.js 或 Clojure），哪怕本地找不到相关工作？我确实爱学习，上班空闲也学新东西，但工作之外真正动手构建的时间有限。我已经对学新语言和框架有点倦了……我在 Perl、Elixir、Haskell、Clojure、Racket、Java 之间转来转去……
throwaway1890查看英文原文
This is good advice, but it's a bit hard to act on. How does one know when to leverage their existing skills to build something vs spending time learning something new and using it to build something (which might not pan out due to lack of experience with that technology, and which will certainly take longer than using what is familiar)? For me, the biggest investment is that of time... and while he provides ideas for small things to do, in the end one really needs to use a technology to grasp it (which he does say). I'm a beginning programmer working on a small team. We won't be hiring anytime soon so many of the things he suggests aren't options. I'm lucky in that I've been able to learn a lot of things across the stack. However, our main language is Perl, which isn't the most marketable language anymore. I have an idea for a useful little site -- something that will look good on a resume, but not something that I can imagine becoming a big money maker of any sort. Do I use my main strengths, my familiar technologies (such as Perl and SQL), to write the site? Or do I choose something that might be an up-and-coming technology (like Node.js or Clojure) even if I can't really find any jobs in my area for them? I do love learning. I spend downtime at work learning new things, but my time outside of work to actually build stuff is limited. I'm getting a bit burnt out on learning new languages and frameworks... I've wandered between Perl, Elixir, Haskell, Clojure, Racket, Javascript/Node, and any number of frameworks for them. I just want to make something solid, but I'm worried that using my Perl skillset will be more of a short term than a long term gain. I know there's probably no easy answer to this question. But it seems to me that it's better to have made something and launched it (even if it doesn't use the sexiest tech) than to have something half-finished stagnate because I don't have the time to learn the ins and outs of the quirks behind some new tech. Does anyone have any insight into handling this? Thanks.
底层和基础概念不会过时，认真开发者应理解从逻辑门到软件的完整系统。
尽管我欣赏文章说的（确实有道理），但我认为在 SMARTS/SKILLS/JOBS 这些部分上，我们正面临相反的问题。现在大多数新计算机科学家/工程师对基础掌握得并不好。你也许会说写汇编（或学汇编）的人很傻，但这大错特错。保持底层计算知识更新，是你在任何抽象层上工作的基础。旧技能中的核心概念，一千年后仍然重要。随着老一辈淡出，我担心我们会失去大量所有编程所依赖的根本性、硬核知识。你很少看到新时代程序员学习内存、I/O 等底层细节。可是将来如果需要修改甚至从接近硬件的层面重建某些东西，我们可能会束手无策。没有那些处理过硬核问题的人，当今年轻一代接班时，我们可能失去这些知识。所以我的观点是：任何认真的黑客都应该能概念化一台从逻辑门到软件的完整机器。理解计算机系统的原始组件，会在其他所有地方帮到你，而且这类知识很可能永远不会过时。
jdefr89查看英文原文
Although I appreciate what the article has to say (indeed its true); I think we are having an issue with the reverse with regards to the SMARTS/SKILLS/JOBS sections. Most new computer scientist/engineers these days DON'T KNOW FUNDAMENTALS WELL. You may say people who code in Assembly (or are learning it) are foolish; that couldn't be farther from the truth. Keeping up to date with your low-level computing knowledge forms a base to work on any other abstraction layer up the chain. The core concepts important in older skills will still be important 1000 years down the road. With the older generation fading out I fear we will lose a lot of the fundamental, gritty knowledge that all other programming is based on. You don't see many new-age programmers learning about low-level details like memory, and i/o. Yet, in years to come if we need to make changes and possibly rebuild some things from close to the hardware we may end up in the dark. Without the people who handled a lot of the hardcore stuff, we may potentially lose knowledge when todays younger generation steps up to the plate. So basically my argument is that any serious hacker should be able to conceptualize a fully working machine from the logic gates to the software. Understanding the primitive components of a computer system helps you everywhere else and will most likely never be knowledge that becomes obsolete.
历次讨论
同类还值得读
用十年时间自学编程（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