职业与工作方法blog.pragmaticengineer.com
有产品思维的软件工程师
The Product-Minded Software Engineer
2019 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章由 Gergely Orosz 撰写，讨论“有产品意识的软件工程师”：他们不只完成需求，还会追问为什么做、理解用户和业务，并主动提出产品改进与取舍。文章梳理了这类工程师的特征、与产品团队协作的方式，以及这种能力对个人和团队的价值。
为什么经久不衰：它把工程师的影响力从“写代码”扩展到“判断做什么、为什么做”，对个人成长和团队协作都有长期参考价值。
HN 评论精选
产品思维在只求功能数量的组织里会让人痛苦：很多功能上线后无人使用、无人维护，工程师的质疑往往被证实。
有产品思维也有坏处：在“勾选式开发”的组织里（只为让功能列表看起来最全），你会问为什么要做这个，得到的回答听起来合理；但做完后没人关注（没有分析、报告、迭代）。一两年后出现大 bug，才发现 20% 用户根本用不了，而功能消失也没人注意到——你怀疑它不重要的预感被证实。我曾在一个公司“最重要”的项目上，团队很大、CTO 每天关注，一年上线后被 CEO 视为成功；一年后很少再听到它，1.5 年后一个 P2 bug 显示整个产品因前端问题已停了三个月。
sdnlafkjh34rw查看英文原文
There is a con to being a product minded software engineer. When you are in organizations that do checkbox driven development (i.e. build features so it looks like your product has the widest feature set), it can be disheartening. You will ask why build this? and will get a believable answer. However, once it get's built you will notice that no one pays attention to the feature (no analytics, no reports, no iteration, etc.). At some point in the future, maybe a year or two down the line, you will notice a huge bug raised with the feature. Whoops for 20% of the users, it didn't work. You feel bad at first for your bug, but then realize, that no users even noticed the feature gone. Your suspicions that you were building something that didn't even matter are confirmed. This has happened to me a lot. I was on a team that was on one of the "most important" projects to the company. We had the CTOs daily attention. You felt important and we had a large team who worked hard to ship it in one year. It was deemed a success by the CEO and myself and many of the team members got staffed on other teams (basically the next highest priority project for the company). Some other engineers got put on legacy duty for maintaining the project. After a year, I barely heard about the project (we had so many new projects) but we still maintained it and it was still on our website. 1.5 years later, I get a p2 bug that basically shows the whole product had stopped working for 3 months due to a front end bug. I got pulled to fix the bug and worked hard to find it and fix, but at the end I was demoralized because I realized my team had wasted a year on a feature no customer cared about enough to complain until 3 months after it stopped working. Basically, it can be really demoralizing to be product minded engineer if your organization is not. This happened in an org that heavily talked the talk about product market fit and testing, but the truth was we were checkbox driven. We just wanted the widest feature set among competitors (even if they didn't always work).
很多工程师私下抱怨需求却不愿向产品方反馈；产品工程师更投入、有软技能，团队文化能鼓励更多人开口。
我见过作者几次，他人很好，我们工作方式相似。我多数岗位先做工程师后转工程管理，文中点很熟悉。常见情况：产品负责人/业务提需求，开发者不问就实现，但午饭时又抱怨需求没价值；被问是否反馈给产品负责人，常看到“不关我事，反正拿工资”的态度。产品工程师对产品更有投入感，也有软技能以业务愿意听的方式影响或反馈。我在团队里培养这种沟通，更多开发者愿意给出有价值的产品反馈，形成正向循环；当然很多人仍只想写代码回家，但团队文化能鼓励没信心的工程师开口。
keyP查看英文原文
I've met Gergely, the author, a couple of times a while back and he's a great guy and I think we work in a similar way. In the majority of my roles I was initially hired as an engineer but then moved to engineering management and the points highlighted in the article are very familiar. I often found that features would be requested from product owners/business and developers would implement it no questions asked but at lunch time, developers would rant about the requested feature's value. When asked if it should be brought to the PO's attention, I often saw the attitude of it not being their problem, they're getting paid either way (whether that's a company culture issue, general developer apathy, or burnt by past experience of questioning management is a different question). I think product-engineers feel a bit more invested in the product and have the soft-skills to influence or provide feedback in a manner conducive to business listening. In my teams, I try to foster this type of communication and I've noticed a lot more developers opening up and providing valuable product-orientated feedback which often has an upward positive spiral of them feeling more appreciated and speaking more. Naturally a lot of engineers still want to just code and go home but team culture can really highlight and encourage engineers who may not be confident to speak up initially. Ironically, as someone with more engineering experience on paper, it's been tricky to find a job directly as any form of product or engineer manager, I always had to go in as an engineer then be promoted after a year or so which isn't always ideal (or referred via a friend). I feel Product and Technical skills are still often considered mutually exclusive a lot of the time but I think that's inertia from when technical skills were still considered a cost to the business.
产品工程师的核心是更偏重“做正确的东西”，早期团队尤其需要；他们还愿意手动支持边缘用户来学习。
“产品工程师”和另一种类型之间的谱系经常出现，我觉得它在招聘和团队建设中被低估。我的理解是你在给两个目标之一加权：1）做正确的东西；2）把东西做正确。早期阶段非常需要更关注 1）的工程师，合适的产品工程师可能 70%/30%。最强的产品工程师还深知手动处理一些案例作为学习手段的力量：小规模时手动处理成本远低于为那种情况开发。所以另一个特征是，他们愿意甚至享受在边缘案例中支持用户、通过与用户交谈来学习。我很好奇公司如何有效招聘或培养这些行为。
daguar查看英文原文
The spectrum of (product engineer) <---> ($NEEDS_A_NAME) has been one I've encountered a lot and which I find is underappreciated in hiring and team-building. The way I think about it is that you're giving weights to one of two different goals: 1. Building the right thing 2. Building the thing right I've found that in early-stage work, you really really need to have engineers who are more interested in (1) than (2). I'd probably say a product engineer who's a good fit for early stage work probably has an 70%/30% mix of what motivates them between these two goals. The strongest product engineers also have a keen sense of the power of MANUALLY handling some cases as a way to learn. At small scale, the cost of manually handling something can be way lower than building for that case. So another attribute I've seen is that strong product engineers are either okay with or even actively enjoy supporting users in those edge cases, talking with them as a way to learn. I'd be curious to know how companies most effectively hire for and/or cultivate these kinds of behaviors in eng teams.
理解用户和上下文是高质量工程决策的前提；产品思维应是资深工程师的默认能力，内部工具也一样。
某种程度上，我发现自己很难在没有理解谁会用、怎么用、为什么需要的情况下工作。这让工程决策困难、维护糟糕（不知道影响），新功能也难界定（真需要处理所有边角情况，还是可以说不支持？）。理解上下文是很多高影响力工作的关键。所以我同意作者说的产品工程师品质（都是好品质），但我认为这应成为任何资深工程师的默认技能，尤其“产品”可以是内部库，不必是面向外部客户的最终产品。
Agingcoder查看英文原文
To some extent, I'm finding very difficult to work on something with no understanding of who is going to use it, how it's going to be used, and why it's needed. It makes engineering decisions very difficult, maintenance work horrible since you don't know the impact, and new features difficult to 'bound' (do I really need to handle all these extra corner cases, or can I just say it's not supported?). Basically, understanding context is key to high impact work in many cases. So, while I agree with OP about the qualities of 'product-minded engineers' (they're good qualities), I believe they should be part of the default skillset of any senior engineer, and especially so since 'product' can be a library shipped internally, and doesn't have to be the final product shipped to clients outside the company.
历次讨论
同类还值得读
用十年时间自学编程（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