编程语言与软件工程2022arxiv.org
游戏化会影响软件开发者：来自 GitHub 的警示性证据
Gamification affects software developers: Cautionary evidence from GitHub
进阶 · 约 45 分钟读完前置知识：软件工程实证研究、因果推断/自然实验基础、GitHub 平台机制
导读
这篇论文研究平台游戏化机制（如徽章、连续提交计数等）对软件开发者的实际影响。作者利用 GitHub 移除「连续提交天数计数器」（streak counter）这一改动作为自然实验，比较移除前后开发者的提交行为变化，给出游戏化会改变开发者工作节奏的警示性证据。
HN 关注点：HN 读者长期对 GitHub 日益「社交网络化」不满，这篇论文用数据佐证游戏化确实会影响开发者行为，且评论中还有 GitHub 员工现身说法。
HN 评论精选
这几条评论里：支持 1 质疑 1 补充 1 亲历 1
支持批评 GitHub 的游戏化是在诱导无偿劳动，并点名了具体的毒性设计。
我很不喜欢 GitHub 变成一个类似社交网络的地方。这些游戏化元素在鼓励人们免费干活，微软多半也心知肚明。GitHub 就该是托管和构建代码的地方，而不是炫耀粉丝数和 star 数的地方。我觉得相当有害的游戏化元素包括：个人主页上的成就徽章、主页高亮展示，以及那个「活动概览」——它用一套极不靠谱的指标来衡量你的工作（代码评审、issue 等）。
c7DJTLrn查看英文原文
I really don't like how GitHub has turned into a social network of sorts. The gamified elements are encouraging people to work for free and MS probably knows this. GitHub should just be a place to host and build code, not to flex your follower or star count. Some examples of gamified elements I find quite toxic: * Achievements on profiles * Highlights on profiles * "Activity overview" which shows an extremely flawed gauge of the work you're doing (Code review, Issues, etc)
质疑反向视角：游戏化提供了正面认可，图表还能帮助自我监测状态。
我要逆着目前的评论风向说：我挺享受这种游戏化体验。因为自己做的开源工作而获得成就认可，感觉很好，说实话这比我为同样付出通常能得到的认可还多。我也喜欢活动图表，它可以兼作我生产力和精力的监测工具：如果我觉得这周过得很糟，但图表并不支持这种感觉，我就更容易阻止自己陷入低落。毕竟我只是个社会性动物，也是一辈子的玩家。这对我有效，但也许不是对所有人都有效。
dleslie查看英文原文
I'm going to buck the comment trend thus far and state that I enjoy the gamified experience. Getting an achievement in recognition of the open source work that I've done feels great, and honestly it's more positive recognition then I would normally receive for that same effort. I also appreciate the activity chart and graph, since they double as a way to monitor my productivity and therefore my energy. If I've felt that I had a bad week and the charts contradict this, then it's easier to stop myself from feeling down on myself. I am just a social mammal, after all; and a life long gamer. This works for me, but maybe not everyone.
亲历GitHub 员工确认移除 streak 计数器是有意设计，认可论文所讨论的改动。
我是 GitHub 的 Martin。我们认为移除连续提交计数器基本是「有意为之」的设计，很高兴它达到了预期效果。连续 100 天不休息地写代码对谁都不好。
martinwoodward查看英文原文
Martin from GitHub here. I think we’d consider this very much ‘by design’ in removing the streak counter so I’m glad it had the desired affect. Coding 100 days straight with no breaks isn’t good for anyone.
补充主页空白往往说明此人在公司做私有项目，公开活跃度不能代表真实工作量。
每当我看到某人的 GitHub 主页很空，我实际想到的是：「啊，这人有工作。」我在这个行业待了挺久，自己也用 GitHub，但主页一片空白，因为我所有的工作都是给私营公司做的。
ehnto查看英文原文
Whenever I see someone with a very limited GitHub presence, what I actually think is "Ah, this person has a job." I've been in the industry for a while now and I even use github, but my profile is blank, because all my work is for private companies.
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2022Hacker News 讨论帖264 分 · 304 评
同领域还值得读
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 分钟编辑精选