【外评】程序员大神每天什么都是时候工作？

共有 207 条讨论

1. 就我个人而言，如果认为提交时间与工作时间有关，我会非常谨慎。

   至少 15 年来，我和我团队里的人都有一个政策，那就是避免在晚上或周末之前合并或提交到公共分支，这样就不会意外地对团队中依赖自动构建和测试的其他人造成危害。我们不分昼夜地编写代码，但要等到早上大家都在的时候才提交/推送/合并到主干分支。

   我知道不是每个人都有这样的政策，但这些都是知名度很高的程序员，他们很可能有自己的复杂因素。比如 Linus，他提交了很多其他人依赖的合并代码；他的代码审查和代码编写可能是分开进行的。

   回复

   1. 关于提交的奇怪政策–为什么不在晚上或周末推送？为什么每个人都不在分支上工作？

      回复

      1. > 关于提交的奇怪政策–为什么不在晚上或周末推送？为什么每个人都不在分支上工作？

         我就是这个意思。我的政策是避免向主站推送。一旦分支里有几个人，我的政策也适用于分支。

         很多人都在分支中工作，但在我工作过的地方，很多人在做他们认为 “小 “的改动时都会跳过分支。在我工作过的一些地方，团队已经决定跳过分支和合并来处理单次提交的变更，因为这会造成历史噪音。

         这样做的目的是为了避免在没有人注意和修复的情况下，将破坏性的变更提交到主版本。

         回复

         1. 我认为造成混淆的原因是，您似乎是说人们在工作时甚至都不提交自己的工作，而只是在推送时才提交。dchest（似乎）是在问，为什么您不在工作完成后提交，而是延迟推送（根据您的政策）？

            回复

            1. 刚才的混乱是我的错，但我想现在已经基本消除了。我最初把它描述为提交，其实我想的是推送，部分原因是我把 git 和 Perforce 的经验混为一谈了。我修改了我的注释，使其更加清晰，这似乎有所帮助。

               问题是有道理的，我们确实经常提交，但我们只避免在晚上向共享空间推送，所以有些提交的时间戳可能具有代表性。根据我的经验，周五提交但周一推送的提交更有可能是在周一推送前修改的。对我来说，第一次提交的时间很少能持续到推送，我几乎总是在代码推送之前就对其进行多次压制。

               回复

               1. 完全正确！此外，如果你花了一整天的时间来完成一个提交，那么在一天结束时，它就会以一个数据点的形式显示在这些统计中，而你在提交前的 8 个小时里也在工作的事实就会丢失。

                  回复

               2. 这并不完全正确。Git 提交有两个时间戳：作者时间戳和提交时间戳。Git 默认只显示作者的时间戳，而且这个时间戳肯定会在`git commit –amend` 和其他操作（比如用 squash 进行 rebase）中保留下来。我曾经遇到过这样的情况，作者时间戳比我最后推送到上游之前的最后一次修改还要早好几个月。

                  不幸的是，TFA 并没有讨论查看的是哪个时间戳，不过这让我怀疑查看的是作者时间戳，因为这是默认的。

                  回复

                  1. > 这个时间戳肯定能在`git commit –amend` 和其他操作（比如用 squash 进行 rebase）中存活下来。

                     你说的只是压卷中的第一次提交，而且假设没有多次压卷，对吗？压卷中并不只有一个时间戳，所以除了一个时间戳外，其他时间戳都会丢失。

                     > 我曾经遇到过这样的情况：提交的作者时间戳比我最后一次修改该提交还要早好几个月，最后才推送到上游。

                     没错，这就说明了为什么看时间戳不能很好地代表工作时间。

                     > TFA 没有讨论查看的是哪个时间戳

                     下面是文章中脚本的相关部分：

                     git log –author=”Linus Torvalds” –date=iso

                     回复

         2. 对于历史噪音，只需在合并前重置，就不会有合并提交了。这真的很简单，而且还能保留分支的使用。

            我们的流程是

            – 为每一个改动创建一个分支 – 使提交相对较小，但完整；每次提交都不应破坏构建和测试 – 当代码准备好合并时，请求同行评审 – 评审通过后，重置到团队的开发分支并合并

            回复

         3. 我们在生产中紧急回滚到上一次的工作部署。这就是当破坏性变更提交到主版本时要做的事。让开发人员直接提交到主版本？这主意糟透了。

            回复

            1. 这是一个很好的策略，在某些情况下可行。防止周末中断取决于每日部署计划吗？当出现破坏性更改时，我通常会先还原，然后再问问题，我想这和您说的差不多…

               > 让开发人员直接向主程序提交？这主意太糟糕了。

               我所在的团队从未禁止向主控提交。我明白他们的想法，也许我也应该这么做，但不管出于什么原因，我去过的地方都没有那么正规，而且他们可能会担心白天人们需要更快地分享东西时，会拖慢周转时间。

               顺便说一句，我说的是 git，也包括 git 之外的其他 VCS。在 Perforce 中，作为一项政策决定，隔离主分支是比较困难的。也许是我所在的团队还不够大，没有人全职负责合并工作……

               回复

               1. > 我去过的地方没有这么正规，他们可能担心白天会耽误周转时间

                  我更担心代码未经审核就提交到主程序。

                  回复

         4. 只有在审查之后，例如 PR 被 X 位审查员接受，才可以合并到主版本，而这很可能只发生在工作时间。我不太理解你们的政策，在任何时候，未经审核就随意提交/推送代码到主版本都不是个好主意。

            回复

         5. 你说的是合并，而不是提交或推送到远程。

            一个人可以整天提交和推送分支。

            在没有提前通知的情况下将它们合并到主干是个坏主意，除非团队已经实施了可以处理这种情况的流程

            回复

            1. 我们很多人都会做 “压扁合并”（使用 git rebase 压缩到 CR 中有意义的点，然后在合并到主分支或特性分支之前再压缩一次）。这样可以创建干净的历史记录，但代价是无法以较高的粒度跟踪他人的工作，也无法在 github 的跟踪器上获得较高的评分。

               回复

               1. 使用 fixup 或 squash 的 Git rebase 交互式提交会将这些提交合并到第一个提交中。因此，时间戳仍能在一定程度上反映工作完成的时间（平均而言）。

                  回复

                  1. 不过，如果至少存在一些偏差，我也不会感到惊讶。例如，在定期举行的 scrum 会议之后，第一次提交会相对较快。至少如果他们是那种会在增量变更后检查点的开发人员。

                     回复

                  2. 你确定吗？

                     在我看来，某人在新分支上进行初始提交的平均时间很可能与他在一般情况下进行提交的平均时间大相径庭。我是不是理解错了？

                     回复

               2. 有时，我只能通过高粒度地跟踪其他员工，来了解他们（或者说两年前的我）在写这篇文章时脑子里在想些什么……逻辑非常有趣。

                  与我共事的最大的 WTF 程序员压扁了他所有的提交。因此，每次提交都是 100-400 行的 Rube Goldbergian 大作。

                  回复

               3. 我不相信 “干净的历史 “能胜过更丰富、更精细的历史。

                  人们普遍认为频繁的小规模提交才是正确的做法，这是有原因的。

                  回复

                  1. 在我对特性分支的几十次提交中，大部分都是 “更新”、”修复测试 “或 “哎呀忘了边缘情况”。但有一次提交的内容是 “some-feature-tag: nice description of the changes (#relevant-pr)”。

                     我不可能为一个分支写多条漂亮的提交信息。

                     如果把合并的重点放在一件事上，你仍然可以获得细粒度的提交。

                     回复

                     1. > 如果将合并集中在一件事上，你仍然可以获得细粒度的提交。

                        没错。Git Flow 就是这么做的。两全其美。

                        回复

            2. > 你说的是合并，不是提交，也不是推送到远程。

               合并和提交都可以推送。我不太清楚你想做什么区分。

               另外，我使用的是 git 术语，但不是每个人都用 git。例如，我在使用 Perforce 的团队中就有这样的经验。

               > 一个人可以整天提交和推送分支。贸然把它们合并到主干是个坏主意。

               没错，就是这样。你同意我的观点。我的政策是在非工作时间将任何新内容放入主分支，因为逃避测试的破坏性修改可能要到工作时间才能修复，而且会妨碍其他人在晚上或周末工作。

               回复

               1. 这篇文章说的是 Git 提交的时间，而不是推送的时间，也不是人们使用其他源码控制系统（如 Perforce）的时间。你说：”如果认为提交时间与工作时间有关，我会非常谨慎”，并以你自己晚上不推送的政策为例，说明 “提交时间 “可能与工作时间无关。现在你又说：”我的政策是不在非工作时间向主干分支提交任何新内容”，也就是说，这是关于推送，而不是提交。

                  这意味着你最初的顶层评论与你正在评论的文章完全无关，这很不幸，因为它是这篇文章的最高票评论。你应该编辑顶层评论以反映这一事实，或者，如果不可能的话，添加一条二级评论以撤回该评论。

                  回复

                  1. 我坚持我上面的评论，避免周五推送而等到周一，往往会导致周一的代码提交时间和周一的合并提交时间。(编辑：顺便说一下，我知道这是事实，因为我们监控了平均提交时间，以确保政策得到遵守）。

                     如果你看一下文章中的代码，就会发现作者并没有过滤掉合并提交。文章中甚至没有出现合并一词。OP 的数据包括合并提交。

                     你试图划出一条硬性的理想化界限，而这在现实公司中并不存在。压制常常发生在推送之前。藏起来过周末而不提交的情况很常见。人们周末不安全地将未提交的变更留在工作区也很常见。在我的经验中，大多数开发人员都不是 git 专家，他们并不总是以最佳实践的方式使用 git。每次在 HN 上出现 git 线程时，这一点都很明显。

                     我说的是提交时间，我的推送策略会影响我的提交时间。你不能指望提交时间来证明什么。

                     回复

                     1. 你试图用 “根据我的经验，大多数开发人员都不是 Git 专家，他们也不总是以最佳实践的方式使用 Git “来为你的评论与一篇关于 Linus Torvalds 等人的开发实践的文章的相关性辩护。也许你不知道，Linus Torvalds 最初编写 Git 的目的，就是为了将他认为的 “最佳实践 “机械化。

                        编辑补充：显然，我的措辞让你误以为我在生你的气，想要攻击你。我不确定那是什么，但那不是我的本意。我只是觉得你说的不对，或者说你的公司可能是对的，但这篇文章不是，我只是想解释原因。我很抱歉用明显带有攻击性的语气写了这篇文章。

                        回复

                        1. 谢谢，是的，我很清楚是莱纳斯写了 git。我不知道是什么让你这么生气，但如果你真的愿意讨论，而不是无论如何都要证明我是错的，我愿意继续讨论。目前感觉是后者，但我认为你没有听清楚或理解我说的话。你好像在做假设。

                           也许你没注意到我在上文指出莱纳斯进行了大量的合并提交，你只是忽略了我之前关于合并提交的观点，而这与我的评论完全直接相关。这篇文章将莱纳斯的合并提交纳入了他的提交时间柱状图中。如果莱纳斯像我一样等待合并，那么数据就会有偏差。如果莱纳斯早上审核代码并发送电子邮件，晚上编写代码，那么数据就会产生误导。

                           回复

                           1. Linus 合并提交的日期和时间是他在自己的本地机器上进行合并的时间，这可能与他推送这些修改的时间不同（鉴于他专门设计了 git 来实现这一功能，他使用这一功能似乎很有道理）。

                              合并提交和非合并提交其实是一样的。唯一的区别是父提交的数量，这与本讨论无关。

                           2. 无论如何，克拉根说得完全正确。

                           3. 稻草人的论点在他们自己的语境中经常是这样的。这并不意味着我错了。@kragen 没有回答我关于合并提交包含在 OP 的文章和数据中的观点，这与我在开头所说的直接相关；合并提交并不代表工作时间，但在这里却被计算在内。代码提交也不一定代表工作时间，这是因为压制、匿名和一般开发实践的缘故，所以我还没有听到任何证据能让我信服。你有什么要补充的吗？

                           4. 合并也是工作。合并的时间表明，这个人当时确实在工作。

                              显然，这种方法是有限的，但在实践中似乎很有效。如果您有证据证明所列程序员的统计数据有误，请与我们分享。

                           5. 你在这里攻击我的诚信是不受欢迎的，也是毫无道理的；这确实让我很生气。我很遗憾在这个主题中浪费了你这么多时间，并假定你是善意的。

                           6. > 你在这里攻击我的诚信是不受欢迎的

                              我绝对没有这样做。为了你的诚信，你可以考虑收回那句不真实的话。我说的任何话都没有攻击你个人的意思。

                              你要求收回我的最高评论，暗示它是翻来覆去和虚伪的，但你误解了我的论点，提出了一个与我的论点无关的反驳观点。这是稻草人，既然你似乎认为 “稻草人 “是评判性的，那就不是。它只是意味着你所反驳的观点与我的观点不同。

                              事实上，你还没有回应我提出的合并提交观点，而 OP 数据中的合并提交与我最初的评论是相关的。

                              > 我很遗憾给了你这么多时间

                              你说得好像我应该感谢你说我的话不真实、”完全不相关 “似的。和我争论，说我试图捍卫一个不相关的立场，这怎么能算是你的善意呢？

                           7. 我认为克拉根的评论是在制造稻草人论点。它们是不必要的对抗。

                     2. > 你不能指望提交时间来证明什么。

                        非常极端的立场！尤其是在话题如此深入的情况下。有时候，随着对话的深入，最好能让自己的观点更具体，而不是一味激进，一味地重复。

                        回复

                        1. 有意思；我完全不认为我说的话极端或偏激。我把它改成一个问题：考虑到在实践中，提交时间经常会在推送之前发生变化，您认为提交时间证明了什么？

                           回复

                           1. 提交时间与代码编写时间有一定关联。这并不完美，但就我个人而言，通常很接近。

                              至于这种相关性是否足够贴近现实，以至于有用，那就要看情况了。

                              我对你的 “提交时间说明不了什么 “断言的理解是，你是说其中没有有用的信息，这似乎是一个激进的立场。

                           2. 提交时间如何更改？

                           3. git commit –amend 会更改作者时间。

                              git commit –amend –reset-author 同时更改作者时间和提交时间。

                              git rebase 更改提交时间。

                              这三个命令都可以在合并和推送前使用，以清理工作。因此，我们无法保证最终提交历史中的作者时间或提交时间准确地代表了工作完成的实际时间。

                           4. 这是不同的提交。我说的是引入并推送时间戳与原始提交不同的新提交，而不是修改特定提交的时间戳。推送的提交的时间戳可能与代码编写时的提交时间戳不同，而且经常如此。

               2. 在我看来，这更像是一种迹象，表明你应该强制执行一项政策，即推送合并按钮必须以测试通过为前提（在成功的应用中，推送 “合并按钮 “应该只是请求自动化应用合并，并在实际推送为新的主版本之前进行测试）。如果你是说有可能出现测试覆盖率不足的破坏性变更，那么我建议需要解决测试覆盖率的问题。这是针对小型 1 人版本库的建议吗？如果您想养成良好的习惯或更勤奋地预防缺陷，可以采纳。当有更多人开始贡献时，这个建议就更适用了。

                  回复

                  1. 我工作过的团队都是通过测试来把关合并的。你说得对，测试覆盖率是不够的。我从未在测试覆盖率足够高的地方工作过，但我真心希望有一天能做到，但根据我的经验，新功能总是伴随着新的破坏和新的测试。

                     > 这是针对一个人的小版本库的建议吗？

                     我从未在自己的版本库中使用过 “等待推送 “策略，我认为我的策略在这种情况下没有任何意义。该策略的目的是防止破坏其他人的程序，而不是防止破坏我自己的程序。

                     回复

               3. 你的原始评论读起来像是只推送到主干分支，所以你要等到工作时间才推送到非主干分支。

                  相对于我日常思考这些问题的方式，我觉得这种措辞很深奥

                  回复

      2. 有自动部署功能的工作场所没有部署窗口，这总是让我感到惊讶。在您所在的地区，自动部署只在 10 点到 3 点之间进行，您可以在这个时间段之外通过重载进行部署，以完成紧急修复。

         回复

         1. 大多数 CI 系统都支持按时间间隔自动运行构建，我想有些系统还支持时间范围。

            从某种程度上说，当你在 CI 系统上运行时，很多 CI/CD 工作都会变得更简单。

            回复

      3. 我们的政策是，只有当人们都在办公室时，才冒险去破坏东西。这是一个很好的概念。

         回复

      4. 我认为这里的 “避免合并或投入公共分支机构 “是指 “避免推动”，特别是 “投入公共分支机构 “这一部分。

         因为很明显，有问题的是推送提交，而不是提交本身（用 git 术语）。

         回复

   2. 这不就是特性或主题分支的作用吗？在自己的小世界里投入，准备好分享时再合并。

      回复

      1. 但很多团队更希望你进行重置，并有一个统一的提交历史，而不是合并提交（所以你的提交反映的是重置到主干的时间，而不是你第一次提交到特性分支的时间）。

         不过，我仍然认为这是一个非常酷的事后估算。

         回复

         1. 因此，您的提交将反映重置到主分支的时间，而不是您首次提交到主题分支的时间） >（因此，您的提交将反映重置到主分支的时间，而不是您首次提交到主题分支的时间

            git 并非如此。默认情况下，它会保留原始提交时间。

            回复

            1. 我想他们说的可能是在重新排序前压制多个提交，创建新的提交。

               回复

               1. 是的，我就是这个意思。我没说清楚，谢谢。一般情况下，一个分支中的所有功能提交都会被压入主干中的一个原子提交中。

                  回复

            2. 它只是调用了作者日期（它记录了一个提交日期和一个作者日期），其中一个日期会通过重定标保留下来。）

               回复

      2. 是的，这就是特性分支的作用。我说的政策指的是人们分享的时候，而不是他们提交到特性分支的时候。抱歉，我一开始只把它描述为 “提交”，这是我的错，不是你的错。

         回复

   3. 我会避免在周末、节假日和假期前部署，但如果你的合并前/提交前测试设置可能会在你登陆时给别人带来麻烦，那你的合并前/提交前测试设置就有问题了。

      回复

   4. 有趣的是，许多病理学家都规定晚上不签出病例（我是否要对这个病人进行癌症-非癌症诊断？此举一般是为了自我保护（疲惫的大脑会做出错误的决定），但住院医生等 24 小时工作的人肯定也不希望我给他们的晚上和周末增加更多工作。

      回复

   5. 看起来你已经解决了合并时间 != 提交时间的问题。话虽如此，虽然很难一概而论地说明提交属于工作流程的哪一部分，但我大胆猜测，提交通常是在工作的最后阶段。鉴于此，提交时间涵盖了提交时间之前的一段不确定时间。因此，早上 6 点没有提交并不意味着这个人早上 6 点没有工作，但很可能意味着他们早上 5 点或 4 点没有工作。

      尽管如此，我们只有少数人的数据点，谁又能保证莱纳斯不是前一天写完代码第二天就提交的人呢？谁又能保证莱纳斯不是前一天写完代码，第二天就提交的人呢？谁又能保证圭多不是一边工作一边进行大量小规模提交的人呢？见鬼，也许他们都把多天的提交都压了下去，只留下一个完全不同时间的时间戳。

      tl;dr：是的，我不知道我们能不能从这组数据中获得那么多可靠的信息。

      回复

   6. 提交时间和推送时间不是同一时间。

      回复

   7. 这些是提交时间，不是合并时间。

      回复

      1. 文章包括合并提交时间；我读了脚本。

         回复

         1. 是的，包括它们，但不只使用它们。

            回复

         2. 即使合并提交也不是推送。

            回复

   8. 是

      我们制定了 “周五无变化 “的政策！以免扰乱人们的周末。

      回复

2. 我的直觉反应和其他人一样–质疑用提交次数来衡量工作时间的有效性。

   但我进一步阅读后发现，这并不是一项研究，它只是一个巧妙的脚本，可以从 github 输出一些数据。所以我打算在我的几个项目上运行一下，看看结果如何，并享受有人把它整理出来的乐趣。

   回复

   1. 我曾在自己的项目上运行过类似的 git 统计脚本（我想这其实是 Debian 的一个软件包），至少对我来说，它们很好地反映了我自己的工作习惯，只是早上会有一两个小时的时间差。

      回复

3. 来自约翰-卡马克

   > 我经常上夜班，白天睡觉，但几乎每次都能睡 8 小时。一周还有 112 个小时！

   https://twitter.com/ID_AA_Carmack/status/932718658366857216

   回复

   1. 很高兴看到有人指出这一点。睡眠是影响代码质量和正确性的最重要因素 https://twitter.com/hillelogram/status/1119709859979714560

      回复

      1. 睡眠是一个非常技术性的问题，它是 “大脑维护时间”。它不是为了节省能量，也不是什么可以/应该绕过的事情（否则我们晚上就会累醒，这对在野外抵御掠食者很有用–大自然为这种关闭付出了巨大的代价）。例如，我发现一旦我开始更加注意睡眠，我的记忆力就会明显改善。我希望我接触到的是这些，而不是 “我几乎不需要睡眠！”的吹嘘文化。

         回复

   2. 完全公开：我绝对不是什么名人，但可能算是个程序员。

      我发现，当我在一个单独的原型项目上进行了几个月的黑客工作后，我的工作时间越来越晚，以至于我最终在凌晨 4 点左右上床睡觉，11 点起床。这真的很难纠正！不过，就工作效率而言，凌晨时分是很难被击败的。

      回复

      1. 我当然也不是名人–但我发现自己也是如此。从午夜到 4 点左右，我的工作效率远远高于一天中的其他时间。不过，有家庭的人很难在这些时间工作。

         回复

         1. 这有一个名字：https://en.wikipedia.org/wiki/Night_owl_(人)

            回复

4. 我是个健忘的人，所以我提交得很频繁，但标签都是 “tmp”，后来我在推送前把它们都压成一个正确的提交。我相信我不是一个人，所以提交时间不能作为晴雨表。

   回复

   1. 我建议使用 “git commit –fixup “或 “git commit –squash”，它们会创建一个特殊命名的提交，这样你就可以在之后使用 “git rebase –autosquash “将所有提交压缩在一起。这真的改变了我处理大型补丁集的方式。

      回复

      1. 你真厉害。

         git 多年来积累了这么多好功能，但它们的可发现性却……并不出色–部分原因是我们现在有了这么多选项，这真是荒唐。这是一个恶性循环。

         回复

      2. git commit –fixup “非常好，我一直不喜欢 “git rebase -i ” 的工作流程。

         回复

         1. 不过，”git rebase -i master”（或其他分支）也没那么糟糕，或者你也可以针对 origin/ 进行重定向。

            是的，–autosquash 看起来不错。

            回复

      3. 很好的建议，谢谢。

         回复

   2. 我不喜欢用 `git stash` 来标记改动组，所以在离开一个有进行中改动的分支之前，我会把它们都提交为 “WIP”。然后，当我返回该分支时，我会检查之前的提交是否为 WIP（`git log -1` ），如果是，就重置它（`git reset HEAD~1`）。这是我发现的处理这个问题的最佳工作流程，而且不会丢失我的提交历史，否则我的提交历史会非常干净。

      回复

      1. 临时分支或标签可能是在 git 中保存修改历史的 “正确 “方法。git stash “主要是为了方便您快速清理工作树，例如从远程调取最新修改。

         回复

         1. 我喜欢为需要隐藏的改动创建一个新的临时分支。当我回到工作中时，我通常会用`git cherry-pick -n `把改动带回我工作的分支。-n 标志会在不进行新提交的情况下将改动剔除，这样我就可以完成我正在做的工作，然后进行正式提交。

            回复

            1. 我用 stgit 来处理这类事情。

               回复

      2. 你也可以使用 `git commit –amend` 来清理 WIP 提交。

         回复

      3. 我讨厌 stash，因为它太容易意外弹出。我只是用了很多分支，熟悉了 git rebase，并学习了 git reflog 以防万一。

         回复

      4. git stash 保存我的东西（已弃用）

         git stash push -m “我的东西”

         回复

         1. GP 想要存储的是历史提交，而不仅仅是工作树的当前状态。从根本上说，`git stash` 无法做到这一点。

            回复

            1. 这就是所谓的分支。GP 所描述的是把所有改动都提交到一个 WIP 提交中。

               回复

               1. 他们描述的是许多不同的 WIP 提交，然后把它们压缩成一个 “正确的 “提交。

                  回复

                  1. 这是一个分支。

                     > 然后，当我返回分支时，我会检查之前的提交是否是 WIP（`git log -1` ），如果是，就重置它（`git reset HEAD~1`）。

                     这是一次提交。

                     回复

      5. 是的，我认为你的工作流程比使用匿名提交更正确。完全打算进入分支的工作应该放在提交中，而不是储藏中。

         回复

   3. 当我在处理一项新变更时，我总是会创建一个新分支，并且（几乎）总是只针对一个提交进行工作。我会不断修改那个提交。一般来说，我的工作票都比较小，每个分支都不会有太多问题，所以维护提交历史并不是很有用。我很确定，在我的 Github 历史跟踪中，”看起来很忙，有很多提交 “的情况确实存在，但我不在乎。

      回复

   4. 你可能会喜欢 Magit 的 WIP 功能：https://magit.vc/manual/magit/Wip-Modes.html

      回复

   5. 在提交 PR 之前，我会将多个进行中的提交合并为一个提交。

      回复

      1. 你用 `rebase` 来做这件事吗？

         回复

         1. 可能是 git 重置。

            回复

            1. 不，最有可能是`rebase -i

               回复

               1. 是的，”rebase -i “用于压扁。

                  回复

   6. 我从没见过有人这么做。请问这有什么意义？如果它只是在本地版本中，而你以后必须做（少量）工作才能把它放回一次提交中，那为什么还要在中间提交随机的东西呢？

      回复

      1. 你有没有在视频游戏中使用过快速保存功能，然后再做一些具有破坏性/危险性/实验性的事情？

         回复

         1. 哦，我用编辑器中的撤消来做这种事。但我想，如果你想做大的改动，这可能是一种方法。我很确定 “git stash/pop “就是用来做这个的，但我也没用过，所以不知道效果好不好。

            回复

            1. git stash 会一直跟着你，而临时提交会绑定到分支上

               回复

      2. 我主要使用暂存区来做这件事。还没有创建提交，但可以把差异处理掉。

         回复

5. 关于是否考虑时区的问题，作者在 [1] 中做了回答：

   > 脚本使用的是作者在提交时在挂钟上看到的时间。我想不出有什么更好的时间可以用来绘制这样的图表了。

   [1] https://gist.github.com/bessarabov/674ea13c77fc8128f24b5e3f5…

   回复

   1. 挂钟是什么意思？他们怎么知道作者提交时的地理位置？我把笔记本电脑的时间设置为我所在国家的时间，因为如果我想知道我现在所在的时区，只要低头看看手表就可以了。

      回复

   2. 我可以想象一个更好的时间：他们家乡的时区。也许某人提交的时间是 +0400，但如果他的家乡时区是 -0700，情况就有点不同了。

      回复

6. 我认为墙壁时间计算有误。

   >> 时间戳是自 1970 年 1 月 1 日以来的秒数。如果我们把 1563188141 转换成更人性化的日期，就会得到 “2019-07-15 10:55:41” – 这是 UTC 时区的时间。然后我们在该时间上加上 “03 “小时和 “00 “分钟，得到 “2019-07-15 13:55:41” – 这就是提交作者在提交时可以在挂钟上看到的时间。

   通常，+0300 表示时间戳位于 UTC 的 +3 小时处。例如，时间戳已经是当地的挂钟时间。偏移量可用于将其转换为 UTC。

   因此，如果作者按照他们写的做了。那么我认为所有数据实际上都是 UTC 时间，而不是当地墙时间。

   回复

   1. Unix 时间总是指UTC 时间 1970 年 1 月 1 日（星期四）00:00:00 之后的秒数。Git 会记录提交者的时区，因为时间通常会转换成人类可读的形式。

      回复

      1. 这是一个关于时间的古老谬误的好例子。你说得基本没错，但你漏掉了闰秒。

         回复

   2. 克里斯-拉特纳的那个肯定不对: https://twitter.com/clattner_llvm/status/1150992062365310977

      回复

7. 但可能存在一个问题–他们会在编码后立即提交吗？

   回复

   1. 另一个问题是，当您旅行到不同的时区时，不一定会更新系统的时区。

      回复

      1. 现在大多数设备不是都配置了自动调整功能吗？

         回复

         1. 我个人不带台式机旅行:)

            一般来说，我在旅行时会带一台轻便的小型笔记本电脑，回家后只需连接台式机就可以完成真正的工作，比如提交代码。

            我知道很多大公司都不允许工程师把源代码放在笔记本电脑上（容易丢失和被盗）。

            回复

            1. 至少，当我在 Github 上处理代码时，谷歌为我破了例。大部分代码都是公开的（或即将公开），因此风险很低。

               回复

         2. 博文中说明它使用的是 Unix 时间戳，这并不考虑时区。

            回复

            1. 是的，这与我们讨论用户在不同时区之间旅行时的设备偏移无关。

               Unix 时间戳总是以 UTC/TUC 表示，无论设备偏移量如何，时间戳都保持不变。

               最初评论中关于用户通常不会调整偏移量的说法是没有意义的，因为无论如何，提交都是以 UTC 保存的。我只是指出许多设备会自动调整偏移量。

               回复

            2. 这是 Unix 时间戳，后跟时区。

               回复

         3. 我的 Linux 和 Windows 10 笔记本电脑都没有。

            回复

            1. 两者都可以通过配置做到这一点，但我不确定默认是否启用。

               回复

   2. 对于一两个孤立的提交来说，这是一个合理的问题。但对于数以百计的提交，我认为情况就不一样了。

      更详细的分析还可以考虑修改的数量。每次提交多少文件？多少行？

      星期也是一个非常有趣的指标，例如在 github 的时间轴上就非常明显。我知道我最忙的时候是周中，周五下午的提交量明显减少，如果周末有提交，信息中很可能包含脏话。

      编辑：我打赌 Brad Fitzpatrick 在 Go（目前的工作？）和 memchached（非目前的工作？

      回复

      1. 这根本不可能–你在写代码之前从不提交，因此任何基于提交时间的测量都会始终偏向较晚的时间。

         回复

   3. 也许他们会在每晚测试成功后，早上第一件事就是提交代码（也许他们根本就忘了晚上提交代码）。

      另一个有用的图表是提交量与时间的关系图（其中提交量是指修改的行数等）

      回复

   4. 我认为每个人的情况都不一样。我通常会频繁提交，但我会把多次提交压成一次。

      因此，我的图表并不能准确地告诉你我在什么时间写代码，而是比如说我在什么时间向同事发送了拉取请求。

      回复

8. 一天中的每一个时间段，就好比问音乐家在什么时间作曲、艺术家在什么时间作画、作家在什么时间写作。当然，我们可以将体力活动视为工作，但脑力活动也是工作，而且先于体力活动。

   即使我们离开电脑，大脑也会在大部分时间里处理手头的问题。我甚至可以大胆地说，当我们离开电脑，不为打字分心时，大脑会更加忙碌。

   回复

   1. > 一天中的每个时段，就好比问音乐家在什么时候作曲，艺术家在什么时候作画，作家在什么时候写作。

      这样看问题毫无用处。你还不如把吃饭或上厕所定义为 “写作”，因为他们可能一边吃饭或上厕所一边思考。如果你去看看真正的作家是如何谈论他们写作的（https://www.gwern.net/Morning-writing），他们中的很多人都会很明确地告诉你，为了不去想写作的事情，他们会利用休息时间去做其他工作，比如通信或与家人/朋友联系。

      回复

   2. 完全正确。在我遇到困难的逻辑问题时，解决这些问题的最佳方法往往是去做其他事情。

      只要把它扔到 “潜意识堆 “里，让我的大脑在后台慢慢咀嚼就可以了。

      回复

9. 由于我们不知道他们的工作模式，所以很难得出任何结论。如果你是在 12 点提交的，这可能意味着你是在 9 点到 12 点之间工作，或者是在 11 点到 12 点之间工作，或者可能只是昨天的工作？谁知道呢。

   回复

   1. 我通常朝九晚五地工作，然后在回家前提交。我可能会在家里再看一遍，然后在睡觉前提交修改，大概在 11 点左右。

      根据这项研究，我将从下午 5 点工作到晚上 11 点。

      回复

10. 作为一个通常在公司里朝九晚五工作的人，大多数人都应该朝九晚五地工作，有谁能解释一下，在他们的公司里，是否有什么规范或规则可以让一个人工作如此不正常的时间？

    像谷歌这样的公司就不那么在意工作时间吗？我无法想象在我工作过的任何地方，有人会在下午 2 点出现，无论他们的工作效率有多高。

    回复

    1. 正如其他人已经提到的，这取决于经理和公司，但我注意到，大多数科技公司在这方面都超级宽松，只要你能完成预期的工作，在一天中的大部分时间都能积极响应（即，与队友的日程安排仍有很多重叠，以便他们可以向你寻求帮助），并能参与代码审查/会议等与团队相关的事情，就不会在意你的工作时间和工作强度。

       例如，我的一些队友的工作时间是 8 点到 4 点，一些是中午到 8 点，还有一些是 9 点到 1 点，然后去健身房/做家务什么的，然后是 4 点到 8 点。只要你能按时完成工作并进行良好的沟通，没有人会在意。

       我个人很喜欢这样，因为有些时候我早上可能感觉一点都不好，所以我会很晚才回家，但晚上 7 点左右回到家后，我又会有一股莫名的能量爆发出来，于是我就坐下来写一些代码。

       请记住，这是把双刃剑，因为你可能会为了完成某个重要功能或修复一个令人讨厌的错误而工作到深夜，从而耽误了团队其他成员的工作。

       回复

    2. 我认为这取决于公司和具体经理的态度。每个季度我都会收到一份项目清单，只需要在季度末之前完成即可。

       值得庆幸的是，我的老板发现我的工作时间安排不正常，工作效率会高很多，所以我倾向于这种自由可能是根据具体情况而定的。

       回复

       1. 我认识一位前微软技术研究员。他告诉我，人们总是对他说三道四，还开玩笑说，如果能成为一名 TL，并有权在下午 3 点离开，那一定很爽。另一方面，他已经很多年没有在办公室喝咖啡看日出了。他告诉我，他尽量确保在凌晨 4 点听到咖啡机响之前不起床。

          此外，在谷歌，我知道有些人一天中有一部分时间在家工作，或者为了避免交通堵塞而适度调整作息时间。尽管经常会有团队范围内的 “核心时间”，在这些时间里，你必须随时准备参加会议。

          回复

    3. 我是一名游戏开发人员，我工作过的大多数公司都希望你在 12 点左右出现，在 8-9 点左右离开。我猜这是一种文化。

       现在我是一名远程承包商，终于可以按照自己的作息时间生活，下午 5 点左右起床。

       回复

    4. 作为一名软件工程师，我从未在一家要求员工早上 9 点上班的公司工作过。现在，在我目前工作的地方，大多数人往往在早上 8-9 点上班，5-5:30 点下班，所以在下午 6 点上班时，我经常会发现自己的办公室里只有个位数的人还在，但我认为这种时间安排通常是由人们的生活义务（主要是有孩子）和个人喜好（天生早起）驱动的，而不是公司的要求。我自己通常早上 9 点左右起床，10:30-11:15 之间到办公室。我在这里已经工作 5 年多了，入职以来每年都有大幅加薪，最近还得到了晋升。在与我的经理交谈时，他们从未把我的工作时间作为负面因素提出来（事实上，我现在的老板自己也倾向于早上 10:30 左右上班，主要是为了避开交通高峰期）。

       回复

    5. 在你证明了自己之后，有些地方会让你逍遥法外。

       回复

    6. Tldr; 小公司。并 “赚到钱”。

       经过 6-12 个月的努力，可能包括工作 12-20 个小时，直到 “哦，该死的装钱 “的问题。并与我的老板进行了讨论。我可以自由调整工作时间。我始终如一地出席会议。但如果我的工作受到外部因素的阻挠，我会在周一请假，这样我就可以在周六工作（周二不受阻挠），以在周一的最后期限前完成工作。我经常在深夜工作，这样我可以有 3-4 个小时不间断地工作。为了避免交通堵塞，我的工作时间大多是 10 点到 7 点。我隐约记得工作时间，平均 36-40 小时或更少。但这样的工作效率要高得多。很多人花 8 个多小时工作，但几乎没做什么事。我的 6 个小时是扎扎实实的工作。这也有助于我控制职业倦怠。

       我有轻微的躁狂抑郁症，没有伴侣和孩子。这对我很有用。见仁见智吧。

       回复

11. 不久前，我作为 CircuitLab（YC W13）的技术创始人为自己绘制了这张图表： https://imgur.com/37mbya5

    有两个惊人的发现（顺便说一下，我是一个 “经常提交小的逻辑变更 “的人）：

    1.我的工作模式似乎出奇地一致，凌晨 2 点到 10 点是睡眠时间，下午 1 点左右是午餐和锻炼时间。(另外，晚上 7 点以后用于见朋友、放松等的平均时间明显减少）。

    2.2. 我的曲线与上午 9:00-6:00 窗口之间的交叉点仅为 53%。如果一个 “传统 “雇主将我的工作效率限制在这个时间段内，那么至少可以一阶衡量这种限制对我个人可能产生的低效率–减少 47%。

    回复

12. Fabrice Bellard 显然在 21 和 22 之间合并了 Qemu 的提交，在 22 和 23 之间合并了 FFmpeg 的提交。

    回复

13. 我总是在 8 点到 16 点之间写代码，有时写到 17 点，但之后就停止了。

    程序员和工程师也有家庭和爱好。

    不要再把 “耐力型程序员 “的神话越吹越大了。事实证明，较短的工作时间与较长的工作时间相比，工作效率会有很大的提升。

    回复

14. > 和时区信息 (+0300)

    > 要只过滤某个人的提交，可以获取该提交的本地时间，并按提交时间的小时数汇总

    因此，如果我没记错的话，这些都是以提交计算机的本地时间计算的。

    回复

15. 我想知道这与年龄有多大关系。

    回复

    1. 我想应该有一点吧。

       我曾经在一天中的任何时间都写大量代码，上班 8 小时，在家 6 小时以上。后来我有了孩子，虽然我仍然每天工作 8 小时写代码，但业余时间已经很少有时间写东西了。

       偶尔我也会有 “某个项目 “在做，但大多是 2-3 天的连轴转，然后是 3-5 天的 “无所事事”。这 2-3 天不是周末，我通常会为此失眠。

       孩子们是无情的，无论你熬夜到多晚，他们还是会在早上 6 点起床，需要你送他们去幼儿园/学校，需要你在下午/晚上（精神上）陪伴他们。

       我想你可以说这两三天的 “软倦怠”。

       我正试图把这种 “爆发期 “改为频率更高、时间更短的 1-2 小时，希望频率的增加能减少 “提升 “时间，同时让自己 “进入状态”。

       回复

       1. 随着年龄的增长，还有其他一些事情会让我们分心。例如，我最近买了房子。现在我总是回家做家务，而不是编码。此外，倦怠也可能发生在我们更容易遇到的突发事件中。我在工作中遇到了一个特殊的冲突，之后的几年里，我基本上失去了加班的意愿。

          回复

    2. 可能还与你是否有孩子有很大关系。我记得莱纳斯说过，在他有孩子之前，他经常在晚上工作，但他不得不停止，这样他就可以开车送孩子上学等。

       回复

    3. 我也想知道同样的问题，以及一个人的习惯是如何随着时间的推移而改变的。我想知道像 Linux 内核库这样的东西是否有足够的历史记录来显示这一点？

       回复

16. 如果你感兴趣，可以自己查看：https://gist.github.com/bessarabov/674ea13c77fc8128f24b5e3f5…

    回复

17. 不错的图表。值得注意的是，图表的比例会发生变化。在每张图中，星号代表不同的提交次数。尤其值得注意的是，Brad Fitzpatrick 在 Memcached 中提交的次数很少。

    回复

18. 工作模式会更有趣。

    贝拉德是否对整个项目考虑了好几天，然后在几个小时内就简单地把它黑掉了？

    他们中有人使用 TLA+ 吗？

    他们是否使用了迭代方法，而最初的几个版本真的是错误百出？

    回复

    1. 从他们提到的项目中，我能看到真正受益于 TLA+ 的只有 memcached。对于大多数项目来说，使用 TLA+ 并没有太大意义，除非你正在编写一个潜在的分布式应用程序。如果你只是想给普通程序建模，那么你最好还是看看 PlusCal，它更偏向于普通程序，而不是设计成分布式的。它可以编译为 TLA+，因此你可以获得同样的好处，但语法更容易理解。

       编辑：此外，如果你想了解著名程序员是如何工作的，那么没有比 Peter Seibel 所著的《Coders at Work》一书更好的资料来源了。http://www.codersatwork.com/。

       回复

19. 这是否考虑了时区因素？

    回复

    1. 第 4 段。

       回复

20. 也许维护者 “早 “提交，合并其他人晚上堆积的工作，而贡献者 “晚 “提交，在工作日结束时？

    回复

21. 我经常在傍晚/晚上编写代码，但我几乎总是让代码休息到第二天起床后再进行审核，然后再提交。

    回复

22. 听到评论中有人谈到工作数小时后再提交，我觉得很有趣。我每工作 30 个小时就会本能地提交一次，尤其是在我觉得有价值的时候。如果公关结果特别嘈杂，我有时会把它们压下来。我想，比较一下提交的平均大小也会很有趣。

    回复

    1. 我不知道，我提交的是逻辑单元。我提交的是有逻辑单元的改动。如果是一句话，就这样。如果是 500 行，就是这样。

       如果工作超过一天，我可能会在下班前提交并推送未完成的内容，否则就不会。

       编辑：虽然后者很少发生。在我看来，如果一个单元需要一整天的工作，也许就需要拆分。

       回复

       1. 我在工作中也想这样做，但代码审查和 Jira 票据增加了很多开销，所以我们把东西混在一起，形成伞状提交。

          这可能是因为我们使用的是 Perforce，默认情况下不做本地分支。

          回复

    2. 在我看来，每次提交后，项目都应该处于工作状态（所有内容都能构建，所有测试都能通过，构建的二进制文件或库都能使用）。此外，如果可能的话，每次提交还应该包含所修改代码的单元测试。

       有时只需编写 30 行代码就能达到这些标准，但更常见的情况是需要编写 100-300 行代码并花费数小时才能达到这种状态。

       回复

       1. 同意。我认为，如果提交的实际上不是功能完整的修改，那么提交历史就会变得混乱。

          回复

23. 如何获取 “本地 “时区。我有时会在设置为 UTC 的系统上提交。我不确定有多少人在 github 等在线工具中准确设置了时区。而且很多开发人员，尤其是知名开发人员经常出差。更不用说搬家了。

    综上所述，未知因素太多，我无法相信这项 “研究”。

    回复

24. 我还做了一个按天计算的明细表（关于 #commits/hour/day 的统计数据）：

    https://gist.github.com/davidalbertonogueira/dfc1b114285523c…

    回复

25. 没有人应该在乎。我是认真的。没有什么超级秘密工作时间能让你成为超级程序员。

    回复

26. 很酷的信息！我一直认为我早上的工作效率更高，但现在我有兴趣计算一下数字，看看实际情况究竟如何。显然，你可以在工作效率高的同时不提交项目，但了解一下还是很有趣的。

    回复

27. > 莱纳斯是 Linux 操作系统的作者

    嗯…不完全是。尽管我是 Linux 内核的忠实粉丝，但托瓦尔兹并不是 Linux 操作系统的作者（如果我们假设 Linux 等同于 GNU 实用程序 + Linux 内核的话）。

    回复

    1. 我们为什么要这样假设？内核绝对是一个操作系统。

       回复

28. 我晚上会写很多代码，然后在反复检查后在白天提交。

    回复

29. 时间是根据所在时区本地化的吗？

    回复

30. 我一直想做一个类似的工作，看看大型科技公司的员工工作时间是多少。

    回复

31. 但是，你相信提交时间真的准确吗？不知道有多少非提交时间会被用于预合并。

    回复

32. 我不明白为什么这么多人对提交不代表实际工作或完成时间的说法大为不满。作者从未说过他认为提交代表了什么，但你们中的许多人却试图从他的方法中找出某种缺陷，并把自己的意思归结到他从未说过的话上。我们只需欣赏它的本质–一个项目中提交的简单直方图。

    回复

33. 旅行会彻底搞砸这一切。在旅途中，我懒得更新 `timedatectl`。

    回复

34. 如果能检查一下人们是否在周末工作，而不仅仅是一天中的时间，应该会很有意思。

    回复

35. 谁在乎？这有什么关系？

    回复

    1. 没错，没人在乎。这个行业正在创造一种名人程序员文化，崇拜和美化他们编写的代码。

       这根本不重要。重要的是在未来的岁月里，谁来维护这一切。(反正他们甚至可能被删除或被超级种子化）。

       回复

       1. 以营利为目的的点击诱饵项目强化了不健康、不现实的数字幻觉，以维持生意，而名人开发者博主为了提升自己的职业生涯也做了很多同样的事情。你不知道他们是如何工作的，也不知道他们是否有能力。更糟糕的是，名人效应往往会毁掉大多数人，因为他们会变得令人难以忍受地自以为是和/或不合作。这类人往往被高估了很多，绝对会摧毁团队的士气。

          回复

36. 但你为什么对著名的而不是有生产力的感兴趣呢？）

    回复

37. 使用脚本时，提交是否以 UTC 时间表示？

    回复

    1. 是以当地时间作为 UTC 的偏移量。因此，如果按 repo 汇集，即使提交时间不同，但在不同时区，13:00 时也可能有两个提交。

       回复

38. 所有这些人都是在美国时区工作吗，还是适合报告用户提交时所在的本地时区？

    回复

    1. 是本地时区。提交日志中有时区信息。

       回复

39. 不幸的是，作者在帖子中只选择了男性程序员。

    回复

    1. 为什么是不幸？还是我漏掉了某种暗示？那么黑人程序员呢？这重要吗？如果有，为什么？

       回复

       1. 假设作者想到了 “史诗级程序员”，却只想到了白人男性。女性和华裔在我们的行业中做出了巨大贡献，但他们的代表性却不足。作者本可以借此机会了解其中的一些人，并为他们点赞。

          回复

          1. 你能举例说明一些享有 “史诗级 “声誉的程序员是女性还是有色人种吗（或者两者都是？

             回复

             1. 作为一名谷歌员工，我首先想到的是桑杰-格玛瓦特（Sanjay Ghemawat）。杰夫-迪恩（Jeff Dean）在谷歌内部被奉为神话级人物，但他与几乎默默无闻的桑杰结成了项目搭档。

                杰斯-弗拉泽尔（Jess Frazelle）也因其在dockerization方面的工作而闻名。

                https://en.m.wikipedia.org/wiki/Sanjay_Ghemawat

                回复

             2. Margaret Hamilton https://en.wikipedia.org/wiki/Margaret_Hamilton_(software_en…

                回复

             3. 在 git 时间内活跃的人：Audrey Tang https://en.wikipedia.org/wiki/Audrey_Tang

                回复

             4. https://en.wikipedia.org/wiki/Yukihiro_Matsumoto

                https://en.wikipedia.org/wiki/Junio_Hamano

                https://nehanarkhede.com/

                https://en.wikipedia.org/wiki/Viral_B._Shah

                回复

40. 整日整夜

    回复

41. 只要适合您…

    回复

42. 罗伯-派克中午吃午餐

    回复

43. 让我们来 “货物崇拜 “一下这个建议吧。同时，让我们用 “是啊，我是在黑客新闻上听到的 “这句话来激怒我们的经理。我在这里等着被降权，回到 666。

    回复

    1. 笑死我了。像这样的 OP 项目充满了人们寻找浅薄的装腔作势的捷径，而不是深入研究的味道。

       回复

44. 作者可能不是英语母语者，所以请轻声纠正：”非著名程序员每天什么时候工作？

    回复

    1. 原文是用俄语写的，所以我猜这是自动翻译。

       回复

45. [已删除]

    回复

    1. 我已经在其他地方评论过这个问题。这有什么问题吗？你是在暗示女性/黑人程序员与众不同吗？

       [1] https://news.ycombinator.com/item?id=20469963

       回复

       1. 不，他是在暗示他们的代表性不足。

          回复

          1. 是的，这有什么关系？代表性不足？谁？那些与众不同却又与众不同的人？我不明白。我看到有几个人的承诺时间正在被分析。如果名单中有黑人和/或女性，那太好了。我没有为此浪费一丝一毫的心思，即使其中有一些或很多人，我也不会去想。我为什么要这么做？只是一些人而已。对某些 “类型的人 “强行规定配额？当然，请便。不过讽刺的是，你会成为你想解决的问题的一部分。

             回复

             1. 我不是提出原始论据的人，但我同意他们说的有道理。

                有人制作了一份 “著名程序员 “名单，其中只包括白人男性。这只会进一步加深程序员都是白人男性的印象，而实际上这个领域更加多元化，即使不多元化，人们也会从各种角度（指导、消除招聘中的偏见等）努力使其更加多元化。

                我并不是在责怪写博文的人，但指出这一点的评论是有道理的，我们应该牢记这一点，并培养一些敏感性，为每个人创造一个更具包容性的环境。

                > 我没有浪费一点心思，即使其中有一些或很多，我也不会去想。

                这就是所谓的特权，意味着你没有受到它的影响，你只是没有发现问题。这是一种可以理解的行为，我不会因此责怪你。但也许将来，如果你、我或其他白人男性能够找到可以引用的资料来源，或创建一个类似的列表，我们可以牢记这一点，并跳出我们在 HN 上生活的泡泡，看看是否有我们之前错过的东西。

                回复

                1. 提到著名程序员，我只想到约翰-卡马克（John Carmack）、格蕾丝-霍珀（Grace Hopper）和莱纳斯（Linus）。不过格蕾丝和艾达都没有使用版本控制，所以他们无论如何都无法入选。

                   还有哪些人们不知道的知名女性/少数派程序员？

                   回复

                   1. 还有两天就是登月 50 周年纪念日了（我刚刚完成了一个关于这个主题的播客，所以记忆犹新），我想说的是：玛格丽特-汉密尔顿（Margaret Hamilton）：玛格丽特-汉密尔顿

                      – https://www.vox.com/2015/5/30/8689481/margaret-hamilton-apol…

                      – https://www.bbc.co.uk/programmes/w13xttx2/episodes/downloads

                      回复

                   2. 在 git 时间内很活跃的人：Audrey Tang https://en.wikipedia.org/wiki/Audrey_Tang

                      回复

                      1. 尽管我的评论被降权到遗忘（我有点预料到了）。我真的很感谢有人不遗余力地举例说明，打破了 “只有白人男性才能成为成功程序员 “的刻板印象。

                         在我人生的大部分时间里，我都在与这种观念作斗争。谢谢！

                         我也非常高兴我们能进行这样的对话。我认为，人们至少应该谈论这个问题，并意识到并非每个人都拥有同样的特权，这一点很重要。再次感谢你们！

                         回复

                   3. > 格蕾丝和艾达没有使用版本控制，因此无论如何都无法进入名单。

                      是的，这种分析不可避免地会过度代表当今的白人男性，因为它是基于 “编程 “的一个子集（即使用 git 的开源项目），而我们已经知道，这个子集绝大多数是向白人男性倾斜的。

                      回复

                2. > 这就是所谓的 “特权”，意味着你没有受到它的影响，你只是没有看到问题所在。

                   什么特权？到底是什么问题？并详细说明为什么是问题。

                   > 但也许将来，如果_你、我或其他白人男性_[……]跳出我们生活的泡沫[……]

                   我不认为自己在这份名单中。我也不知道你说的泡沫是什么。请详细说明。

                   回复

46. 我不知道这些 “名人 “到底是谁！

    回复

    1. 在目前活跃的程序员中，谁不在这份名单上？

       我认识名单上一半左右的程序员（主要是我使用的软件的作者）。我也许能说出几个同样有名的人，但更有名的人就不多了。

       编辑：我回去数了数。我认出了 7 个名字中的 4 个。

       回复

       1. 公平地说，每个社区都有自己的英雄。例如，生活在 MS 生态系统中的大多数人可能完全不了解贝拉德这样的人。

          回复