职业与工作方法monicalent.com
作为初级开发者，我丢掉的那些“绝对真理”
Absolute truths I unlearned as junior developer
2019 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是开发者 Monica Lent 的一篇博客文章，盘点她在初级开发者阶段奉为"绝对真理"、后来在工作中逐渐推翻的观念：比如测试人人都写、代码质量高于一切、"够用就行"、技术能力最重要等。文章强调的是：很多看似普适的规则，其实取决于具体项目、团队和商业环境。
为什么经久不衰：它把每个工程师都会经历的"从教条到权衡"的成长过程写得具体可对照，且评论区老手补充了大量亲身教训，今天读依然有共鸣。
HN 评论精选
用一组"初级时以为／资深后明白"的对照，说明很多信念只是视角问题。
我当初级程序员的日子比你们中一些人出生还早，但我想到这么一组对照：初级时以为——报告操作系统层面的 bug，资深同事不会信你，只会觉得你在为自个儿的 bug 找借口；当了资深才明白——如果初级程序员跟我说他发现了系统级 bug，我也不会信，会让他先回去查自己的代码。初级时以为——遗留代码很难读；资深后明白——我自己写的遗留代码也很难读。初级时以为——技术能力最重要；资深后明白——沟通能力最重要。初级时以为——新技术能解决老问题；资深后明白——新技术会制造新问题。
beat查看英文原文
Admittedly, my first days as a junior programmer were before some of you were born, but I'm thinking of a particular format here... Learned as junior: If you report an OS bug or some other deep problem, seniors will not believe you and assume you're making excuses for your own bugs and lack of understanding. Understood as senior: If a junior programmer tells me they found a system-level bug, I won't believe them and will tell them to go figure out what's wrong with their code. Learned as junior: Legacy code is hard to read. Understood as senior: Legacy code that I wrote myself is hard to read. Learned as junior: Technical skills matter most. Understood as senior: Communication skills matter most. Learned as junior: New tech solves old problems. Understood as senior: New tech creates new problems.
代码只是手段，用户和公司真正付费买的是问题被解决。
对我来说最大的顿悟是：代码本身并不重要。当然，对我们来说重要，这是我们的手艺。但说到底，代码不重要。对终端用户来说，重要的是我们解决了他们的问题，让他们能把活干下去，而且尽量轻松——这才是他们付钱买的东西。对我们所在的公司来说，重要的是解决用户的问题，并且做得又快又省钱，成本低于客户付的钱。当然，长期要持续做到这点，我们需要创新、做架构、守住标准、控制技术债，这些合起来就是"把代码写好"。但那只是手段，用户并不在乎点下按钮时后台惊醒了什么怪物，只要最后弹出他要的结果。
taneq查看英文原文
The big one for me was the realisation that the code doesn't matter. I mean sure, it does, to us. It's what we do. But really, code doesn't matter. To the end user, what matters is that we solve their problem. We let them do their job, and we make that job as easy as possible. And that's what they pay us for. And to the company we work for, what matters is that we solve the end user's problem, and that we do so in an expedient and economical manner, so that it costs less for us to do so than the customer pays us. Of course, for us to continue doing this, in the long term, we need to innovate and architect and uphold standards and stay on top of technical debt. And all of that put together is "make the code good". But that's an end to the means, and the customer doesn't care what horrors awake when they click that dialog box button as long as the result they needed pops out at the end.
反驳"够用就好"：没有质量下限，代码库会迅速腐坏，应追求"约束下的最好"。
总体是好文章，但我完全不同意"够用就好"这个说法。我参加过很多代码评审，开发者以"够用了"为由顶回来。你必须维持一个明确的质量下限，否则代码库会飞快地烂掉。最近有次评审，有人写 Cassandra 先读后写来防重复，被说成"够用了"，因为重复"大概不会经常发生"；可一旦重复，客户体验会非常糟。我强硬反对，逼他把整段代码重写。这种场景下"够用"真的行吗？我的标准比这位开发者高得多，我坚持自己的判断。我们有幸被委派去解决客户问题，如果每次都只求"够用"、而不是"在给定约束下做到最好"，我认为职业生涯不会太成功。时间和成本上总要做取舍，但最好的开发者是能在特定约束下给出最好方案和最好代码的人。
docker_up查看英文原文
Overall a good article, but I completely disagree with the notion that "good enough is good enough". I've been in a lot of code reviews where developers push back because it's "good enough". You need to maintain a defined level of quality otherwise codebases go to shit very, very fast. I was recently told in a code review that a Cassandra read before a write (to ensure there were no duplicates) was "good enough" because a duplicate "probably wouldn't happen very often". Meanwhile, the consequences of a dupe would lead to a pretty bad customer experience. I pushed back hard and forced the developer to rewrite his entire code. Would "good enough" be okay in this situation? My bar is much higher than this developer and I stand by my decision. We have the luxury of being tasked with solving customer problems and if we only strive for "good enough" every time instead of "the best I can do within the constraints I'm given", then in my opinion your career won't be very successful. We always have to make the best tradeoffs when it comes to time and expense, but the best developers are the ones that come up with the best solution and the best code that fits in a particular constraint.
是否补测试要算投入产出：老而稳定的系统未必值得 retrofit 单元测试。
> 所以你可以想象，我第一天到一家创业公司上班时有多惊讶：完全没有测试。前端没有，后端也没有，就是没有测试。 这段太有共鸣了。我刚读完一本 C 语言入门书，满腔热情地建议给遗留软件加单元测试，当时真觉得自己在帮大忙。产品负责人倒是很厚道，没训我，只是很讲道理地说："这套软件很老、相对稳定，大概五年内就会下线或停掉。为了给这么老的东西补单元测试，等我们写完测试六个月后产品就被砍了，这些人力不值得。"
AdmiralAsshat查看英文原文
> So imagine my surprise when I showed up at my first day on the job at a startup and found no tests at all. No tests in the frontend. No tests in the backend. Just, no tests. That one hits home. I felt like I was being so helpful when I, fresh-eyed after finishing some entry-level C language book, suggested that we should implement unit tests to the legacy software. The product lead, to his credit, did not chew me out, but stated very reasonably, "This software is old, relatively stable, and will likely be dead or sunset in five years. It's not worth the man-hours it would take to try retrofitting unit tests onto a piece of software this old, only for the product to be killed six months after we finish writing 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