编程语言与软件工程2017arxiv.org
论软件开发者的不快乐
On the Unhappiness of Software Developers
入门 · 约 45 分钟读完前置知识：软件工程基础、实证研究方法基础
导读
这篇论文通过分析开发者论坛等数据，研究软件开发者的不幸福感及其成因，列出了最常见的十大不快乐原因，如陷入问题解决、时间压力、糟糕的代码质量等。论文指出开发者整体上是略微偏幸福的群体，且大部分不快乐的根源属于外部因素（如管理问题），因此改善空间较大。
HN 关注点：HN 读者多为开发者，论文总结的不快乐原因与他们的日常体验高度共鸣，讨论焦点集中在'快速交付功能'文化对代码质量和幸福感的伤害，以及外部因素是否真的比个人心态更可控。
HN 评论精选
这几条评论里：支持 1 补充 2 亲历 1
支持十大不快乐原因反映了'快速推功能'文化牺牲了质量与规划
给只扫一眼的人：论文列出的开发者不快乐十大原因：1. 陷入问题解决 2. 时间压力 3. 糟糕的代码质量和编码习惯 4. 表现不佳的同事 5. 觉得工作力不从心 6. 枯燥重复的任务 7. 无法解释的代码故障 8. 糟糕的决策 9. 强加的开发限制 10. 个人问题（与工作无关）。这些我大多经历过，它们恰恰戳破了'现代'软件工程师的信条：快速推功能。代码质量、充分的解释、合理的规划和宽松的时间表都成了次要考虑。
dvt查看英文原文
For those just skimming, here are the top 10 reasons for software developer unhappiness, according to the paper: 1. Being stuck in problem solving 2. Time pressure 3. Bad code quality and coding practice 4. Under-performing colleague 5. Feel inadequate with work 6. Mundane or repetitive task 7. Unexplained broken code 8. Bad decision making 9. Imposed limitation on development 10. Personal issues – not work related I've dealt with most of these, and I think they betray the mantra of the "modern" software engineer: push features fast. Code quality, adequate explanations, proper planning, and lenient time tables are an afterthought.
补充研究印证了'问题多源于管理不善'的共识，但样本性别严重失衡
冒着确认偏误的风险说，这似乎印证了开发者社区的普遍看法：开发者个体上是乐观的，问题主要归咎于管理不善或其他外部因素。论文也提到'绝大多数不快乐的原因属于外部类型'，由于外部原因比内部原因更容易影响，且一次能惠及多名开发者，这意味着实践中有很多改善条件的机会。另外值得注意的是，这项研究男性占比极高（94% 对 5%），这可能是不确定性的来源。
Afforess查看英文原文
At the risk of confirmation bias, this seems to back fairly common beliefs in developer communities... namely that developers are individually optimistic and problems are largely the fault of mismanagement or other externalities. > software developers are a slightly happy population > the vast majority of the causes of unhappiness are of external type. Since external causes may be easier to influence than internal causes, and since influencing them will impact several developers rather than only one at a time, this suggests that there are plenty of opportunities to improve conditions for developers in practice. Also noteworthy: this study skewed highly male (94% v 5%). This may be a source of uncertainty.
亲历亲历：把工作当打工而非事业、保持边界感反而更幸福
当我快速跳槽涨薪、不再把公司的事当成自己的事业后，获得了一定程度的幸福感。这是别人的生意，我只需完成他们要求的事。出了问题，要么走人要么去修，事情耗时那是他们的时间。我早八晚四，不带电脑回家，把公司的低效看作我用来学习和实验的机会。我薪水够用，也不想爬职业阶梯，别人也许有更高的追求。
ThomaszKrueger查看英文原文
I achieved some level of happiness when I managed to go up the earnings ladder (move frequently, move fast) and stop behaving if it was my own business. It is someone else's business, and I am there to do what they ask me. Which may or may not match to what they need, but that's not for me to decide. When things go wrong, you either move on or start fixing things, and that perpetuates your job (hopefully). If things take more time, it is their time. I come in at 8am, leave at 4pm. I don't take my laptop home. I don't work from home. I see their inefficiencies as opportunities for me to spend time on things like learning and experimenting. But that's me. I get paid enough, I don't need or want to go up the "career ladder". Others may have loftier goals.
补充给出应对不快乐来源的实用建议：反向面试、接受不完美、正视遗留代码
几点应对建议：面试时反向面试未来的同事和公司，提前发现不匹配；接受大多数软件不需要完美，达到业务可接受的质量即可，线上出 bug 就专业地处理，别说'我早说过'；警惕大型瀑布式流程中的功能膨胀，可建议在需求阶段收集系统使用率指标；至于遗留代码，搞懂并修复无法解释的坏软件其实会带来某种满足感。
matt_s查看英文原文
A couple things to combat some of these: - When interviewing for a new role, interview the people you will work with and ask questions about the company. Interview them. Discovering during interviews that an employer or co-workers aren't a good match for you is the best place to figure that out. - Realize and accept that most software doesn't need to be perfect. There is an acceptable level of quality and then after that it doesn't matter to the business. Sure its likely someone else's money but that contributes to unhappiness. When production bugs happen, tackle them like a professional and save the "I told you so's". - Same can be said for large waterfall driven software processes. They tend (not all but many in my experience) to have a lot of feature bloat of things people want but never actually use. This could be borne out of politics or appeasing people, misrepresented requirements or the business changes faster than software delivery. Recognize if you work in a shop that does this and come to terms with it or suggest gathering metrics on usage of your system as part of your requirements process. - A lot of the reasons stem from existing software and issues it has. You might think to steer clear of old code and work at a startup or greenfield project where everything is new. There is a certain satisfaction, maybe enlightenment is a closer word, when you figure out unexplained/broken software and fix it. Have you felt that? You'd be amazed what little fixes to do quality of life for the people using the software. "I am one with the code and the code is one with me".
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2017Hacker News 讨论帖242 分 · 140 评
- 2022Hacker News 讨论帖140 分 · 132 评
同领域还值得读
Google 的软件工程（2017）
Software Engineering at Google (2017)
介绍了 Google 的软件工程实践，包括其单一代码库（monorepo）、几乎全部开发在主干进行而非分支、代码审查、构建系统 Blaze、协议缓冲区等工具与流程，并讨论了频繁重…
编程语言与软件工程2017 · 1,127 分 · 465 评 · 引用 15入门 · 约 45 分钟编辑精选Peter Naur：编程作为理论构建 (1985)
Peter Naur – Programming as Theory Building (1985)
Peter Naur 1985 年的经典论文《Programming as Theory Building》提出：编程的本质不是写代码或文档，而是在程序员头脑中构建对程序及其运行…
编程语言与软件工程2016 · 629 分 · 74 评入门 · 约 45 分钟编辑精选SciPy 1.0：Python 科学计算的基础算法
SciPy 1.0: fundamental algorithms for scientific computing in Python
这篇发表于 Nature Methods 的论文介绍了 SciPy 1.0——Python 科学计算生态的基石库，涵盖其核心算法模块（优化、积分、插值、线性代数等）、软件架构与社…
编程语言与软件工程2020 · 387 分 · 98 评入门 · 约 45 分钟编辑精选Lisp 的历史（1979）
History of Lisp (1979)
这是 Lisp 发明者 John McCarthy 于 1979 年为 HOPL（编程语言史）会议撰写的回顾文章，讲述 Lisp 的起源、设计动机与早期演进，文中也涉及 if 表…
编程语言与软件工程2018 · 352 分 · 44 评入门 · 约 45 分钟编辑精选使用 NumPy 进行数组编程
Array Programming with NumPy
这篇 Nature 文章介绍 NumPy 的数组编程模型及其在科学计算中的核心作用：以 ndarray 为中心，通过向量化操作让 Python 高效处理多维数组。
编程语言与软件工程2020 · 318 分 · 134 评入门 · 约 40 分钟编辑精选