职业与工作方法jlongster.com
我如何成为更好的程序员
How I Became a Better Programmer
2017 — 2020，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 jlongster（James Long）的一篇个人随笔，回顾他在编程生涯中如何变得更好，并给出关于学习、工具/框架、代码形式与重复等话题的建议。评论区围绕其中一些有争议的观点展开讨论，也补充了换环境、从零造轮子、理解商业与 MVP 等成长经验。
为什么经久不衰：它讨论的是程序员成长中反复出现的核心矛盾——工具与基本功、抽象与重复、舒适区与学习——因此多年后仍能引发共鸣和争论。
HN 评论精选
批评文章淡化代码形式与 DRY，强调持续学习和可读性。
这里有很多有价值的内容，但有几件事我要提出异议。标题用过去时，好像他认为这段旅程已经完成；好在文章本身没有这个意思。但专业人士的关键技能是持续学习——不要满足于自己已经“更好”，而要每天变得更好。我也强烈反对“忽略代码形式”的建议：代码被读的次数远多于被写，提升自己和队友的理解回报巨大。尤其“别在意 DRY、随便重复”暴露了常见误解——DRY 不是字面意思，而是承认重复往往暗示着更深层的规律；随意复制只会制造更多 bug。
couchand查看英文原文
There's a lot of value here, but I have to raise concerns about a few things. First, the title: written in the past tense makes it seem like he believes the journey is complete. The article itself doesn't convey that message, fortunately. But I think it's worth noting that a critical skill for a professional is constant education - don't be satisfied that you're already "better", get better every day. I also strongly disagree with the suggestion that you should ignore the form of your code. Code is read many, many times more than it is written, so improvements to your own and your teammates' understanding can pay huge dividends. In particular, the advice to "not worry about" DRY and duplicate freely reveals a common misunderstanding. DRY shouldn't be taken literally, it is a recognition that repetition is evidence of some greater underlying truth. By duplicating freely rather than thoughtfully avoiding duplication, you're just creating opportunities for bugs.
舒适区意味着停止学习，换环境能培养适应不同约束的能力。
我的建议是：当你对当前工作感到自信/舒适时，就该换团队或公司了。事情变容易，往往意味着你停止了学习。我同意关于工具的说法：会最新 ES6 特性和框架并不能让你成为更好的程序员。真正让你变好的是适应能力，以及针对不同情境和环境（可扩展性、稳定性、交互性、安全性、时间、监管等约束不同）调整方法的能力。我待过很多公司（平均 6 个月到 1.5 年），每次的环境和流程通常都很不一样。换过几次后，在不同公司之间流动会更容易——你学会写普遍可接受的代码，而不只是某家公司内部能接受的代码。
jondubois查看英文原文
My advice is that whenever you become confident/comfortable in your current work, that's when you have to change team or company. Whenever it gets easy, it means you have stopped learning. I agree with what was said about tools; it doesn't make you a better programmer to know all the latest ES6 features and frameworks. What makes you a better programmer is your ability to adapt and customize your approach to different situations and environments (with different scalability, stability, interactivity, security, time and regulatory constraints). I've been through a lot of different companies (I usually stay 6 months to 1.5 years each on average) and the environments/workflows are usually VERY different each time. After changing a few times, it gets easier to move between different companies - You learn how to produce code that is universally acceptable and not just acceptable within the confines of a single company.
从零写数据库抽象层和 MVC 框架能深刻理解接口设计、模块化与框架作者的付出。
大约十年前 PHP 世界 OOP 刚兴起时，我因为厌倦当时的 ORM（Doctrine、Propel、ZF）而写了自己的数据库抽象层。这让我明白什么构成漂亮的流式接口、实现起来有多难，也帮助我在代码层面思考开发者体验。后来我又从零写了 MVC 框架，因为觉得其他框架太重；这让我更深理解应用开发、代码模块化/组织和性能策略。它让我学到：创造看起来轻松易用的东西其实非常难。这段经历也让我对在宏观层面写框架/库的人有了新的敬意——他们投入了很多思考和热爱。
jaequery查看英文原文
About a decade ago when OOP was just booming in the PHP world, I wrote my own database abstraction layer because I was a bit tired of the ORM's that existed at the time (Doctrine, Propel, ZF). Taught me what makes a beautiful fluent interface and the difficulties of achieving them. Helped me to think about UX experience at a code level, trying to achieve an interface for developers that fits all ages. That was an eye opening experience. Then I wrote an MVC framework from scratch because I thought others were too heavy (ZF, Symfony, etc). It helped me understand an application development at a deeper level, figuring out the best strategy for code modularization, organization, and performance. It helped me to learn creating something that looks so painlessly easy to use is a pretty difficult task (there will always be something ugly sticking out). It took me on a ride of what happens with extreme level of abstractions breaking up code for each roles and a simpler route much like the Sinatra / Express bootstrap approach. I've found a new level of respect for those who develops codes at a macro-level (frameworks / libraries). There are lot of thoughts and love been applied to them. DHL (Rails) is up there, as well as John Resig (jQuery). I'll also give a shout out to Sequel (Jeremy Evans) while at it for creating an ORM that is almost perfect. Vue.js (Evan You) also particularly deserves a lot of credit for what he is doing in the front-end world. I like React too, can be fun, but I did not like the whole Redux experience. I think what makes a great programmer is that they are able to think at a macro-level, thinking about how 'others' will use and apply the code, and making it look deceptively simple.
懂商业和 MVP 能帮助程序员接受先上线后优化。
还要学会经营企业。表面上奇怪，但理解后很有力。了解企业如何运作、现金如何流动、人/场地/软件/硬件/会计/律师等有多贵，你就会开始理解为什么 MVP 是强大工具，也会更欣赏敏捷实践。做 MVP 时你写尽可能少的代码、跳过优化，同时向能告诉你下一步方向的人提供价值。这是商业逻辑：企业需要尽快进入市场并尽快获得反馈；否则你可能花三年写技术栈，发布时世界两年前就已转向。了解企业运作后，你会开始明白：用不那么理想的代码库先进入市场其实可取、值得拥抱。钱烧得很快，所以应学会为进入市场而写代码，而不是（至少暂时不是）追求最快的代码。我合作过的最好的程序员，都是能快速做出东西、之后再优化的人。
movedx查看英文原文
Also learn how to run a business. A weird suggestion on the surface but actually very powerful when understood. In short by learning how a business operates, how cash flows and how expensive things are (people, buildings, software, hardware, accountants, lawyers, ...) you'll begin to understand why an MVP is a powerful tool. you'll also appreciate Agile development practices more too. With an MVP you're writing the least amount of code possible, and skipping optimisations, whilst also providing some value to people who can tell you what direction to go in next. That's a business thing - the business needs something in the market ASAP and it needs feedback ASAP. Without this you'd write your stack for three years and then release to a world that moved on two years ago. When you learn how a business is run you begin to understand that getting to market with a less than ideal code base is actually desirable and something to embraced. All of sudden you'll come to understand that money burns quickly so you should learn to develop code to get to market and not to be the fastest code it can be (yet, at least.) I find the best programmers I've worked with are those that can produce something quickly and optimise it later on.
历次讨论
同类还值得读
用十年时间自学编程（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