我认识的最糟糕的程序员

251 条评论 | |

衡量开发人员工作效率的最大好处是，你可以很快找出那些糟糕的程序员。我想给大家讲讲我认识的最差的程序员，以及我为什么要把他留在团队里。

几年前，我在 Twitter/X 上写过一篇关于我认识的最好的程序员的文章，我应该把它写成一篇博文。现在，我也应该向大家介绍一下我认识的最差的程序员。他的名字叫蒂姆-麦金农（Tim Mackinnon），我想让你们知道他的工作效率有多低。

我们当时在一家大银行为一家知名软件咨询公司工作，这家银行决定引入个人绩效指标，”用于考核和个人发展目的”。这在组织内部层层传达，并在我们的团队中以故事点的交付量作为衡量标准。这是部门经理经过深思熟虑讨论后做出的决定，他知道你不应该衡量代码行数或发现的错误，因为人们很容易玩这些游戏。

相反，我们会衡量已交付的故事，也可能是故事点（事实证明这并不重要），因为这些故事代表了业务价值。我们当时使用的是 Jira 这样的工具，人们会把自己的名字写在故事上，这样就能非常容易地生成这些生产率指标。

这让我想到了蒂姆。蒂姆的得分一直是零。零分！不仅仅是低，也不仅仅是呈下降趋势，而是真正的零。一周又一周，迭代又迭代。蒂姆得了零分。

很显然，蒂姆必须离开。这就是经理的结论，他让我做出必要的安排，把蒂姆调走，换上一个真正能讲故事的人。

我断然拒绝了。对我来说，这甚至不是一个艰难的决定，我只是拒绝了。

你看，蒂姆的工作效率之所以是零分，是因为他从来没有参加过任何报道。相反，他每天都会和不同的队友配对。对于经验较少的开发人员，他会耐心地让他们开动脑筋，同时引导他们找到解决方案。他不会挤兑他们，也不会训斥他们，而是让他们花时间学习，同时精心设计洞察和学习的时机，通常是苏格拉底式的问题、“如果”、“怎么办”。

与前辈们在一起更像是共同创造或切磋；将不同的世界观应用到问题中，创造出比我们自己想出来的更好的东西。蒂姆是一位出色的程序员，与他合作总能学到一些东西。

蒂姆交付的不是软件，而是一个能够交付软件的团队。因为蒂姆的加入，整个团队变得更有效率、更有生产力、更团结、更习惯化、更有趣。

我向经理解释了这一切，并邀请他不时来观察我们的工作。每当他来的时候，他都会看到蒂姆和另一个人坐在一起，做着 “他们 ”的事情，可以肯定的是，这件事情的质量会比蒂姆不和别人配对的时候好得多，价值实现的时间也会大大缩短–是的，你可以做得更好、更快、更便宜，只是需要遵守纪律。

最后，我们留住了蒂姆，并悄悄放弃了个人生产率指标，转而实行团队问责制，跟踪并庆祝我们作为一个高绩效团队为组织带来的业务影响。

简要说明

通过各种方式衡量生产率–我支持问责制–最好是以节省、产生或保护的美元来表示有形的业务影响。这通常很难做到，所以替代业务指标也可以。

只是不要试图衡量一个单位在复杂的适应系统中的单独贡献，因为这个问题的前提是有缺陷的。

例如，DORA 指标是关于工作系统如何运作的，无论是作为韦斯特鲁姆文化指标，还是作为生产中的技术变革流程。它们衡量的是引擎，而不是单个活塞的贡献，因为这毫无意义。

另外，如果你有机会与蒂姆-麦金农（Tim Mackinnon）共事，一定要去。

本文文字及图片出自 The Worst Programmer I Know

你也许感兴趣的：

共有 251 条讨论

  1. 在我看来，衡量开发人员个人生产力的想法有点荒谬。我并不是说我们所做的事情有多神奇，只是变量太多了。

    衡量故事点或代码行数与生产率恰恰相反。这会鼓励开发人员做尽可能多的无意义工作。我希望开发人员能简化任务或使用现有工具，这意味着减少编写代码的时间。他们从了解另一种方法中节省下来的工作价值很高，但很难衡量。

    你想要的是衡量业务成果，但这些成果很难归因于某个特定的开发人员。

    我认为，不幸的是，我们在这里只能凭主观判断。我认为，与其假装我们掌握了某种科学知识，不如承认我们无法衡量这一点。

    回复

    1. 我有个总监对 Github 的企业统计数字很着迷。他禁止人们压制提交，并告诉人们每天都要提交，即使你正在做某事。这样他就能知道谁写的代码最多。

      我们的一位实习生任期将满，这位主管想聘用他。他认为这个实习生写的代码量非常惊人。问题是这个实习生写得不好，所以我们让他写单元测试。然而，他也不擅长写单元测试。他会先运行代码，然后写出执行当前结果的测试，而不是考虑当前行为可能不正确。幸好在我和其他人解释了为什么实习生有这么多提交和这么多行代码后，我们才没有聘用他。

      回复

      1. 这让我想起了一个老笑话：一个警察拦下了一个穷困潦倒的司机。司机抱怨说：”可我一次事故都没出过。”警察回答说：”是的，可你已经造成了几十起事故。”有些人就是无视这些事故。

        有些人就是对他们身后留下的破坏痕迹视而不见。

        回复

        1. “几乎每个软件开发组织都至少有一名开发人员将战术编程发挥到极致：战术龙卷风。战术龙卷风 “是一个多产的程序员，他编写代码的速度远远超过其他人，但工作方式却完全是战术性的。当需要快速实现一个功能时，没有人比战术龙卷风完成得更快。在一些组织中，管理层将战术龙卷风视为英雄。然而，战术龙卷风留下的却是破坏。将来必须处理其代码的工程师很少把他们视为英雄。通常情况下，其他工程师必须收拾战术龙卷风留下的烂摊子，这让人觉得这些工程师（他们才是真正的英雄）的进展比战术龙卷风慢”。- John Ousterhout，《软件设计哲学》

          回复

      2. 这让我想起了我曾经认识的一位经理和一位 QA。QA 是个好人，但却是个糟糕的 QA。他会因为最武断的准则而让故事失败。故事是关于改变主页字体大小的？他会因为无法登录而失败（他在验证服务进行计划维护时进行了测试）。

        经理很喜欢这个人，多次提拔他。最后，其他员工厌倦了被跳过晋升的机会，纷纷离开公司，造成了一场小规模的人员危机

        回复

        1. 我们也有这种情况，但是……至少我们有一支专门的质量保证团队。他们整天都在确认我们写的东西是否符合规范。我们花了很多时间来解决实现、规范和测试之间的差异，但当东西从另一端推出时，它们还是能用的。

          回复

          1. 是啊，一个好的质量保证团队能让人高枕无忧。

            回复

        2. 我想几乎每个人都曾与这样的人打过交道。

          回复

          1. 就像癌症的产生和发展源于自然细胞过程的失常一样，这似乎也是一种组织癌症，存在于任何规模足够大的公司中。

            回复

          2. >故事是关于改变主页字体大小的？他失败的原因是他无法登录（他在验证服务进行计划维护时进行了测试）。

            离岸质量保证团队的平均水平。

            回复

        3. 然后，其他员工发现这个世界就是这样的：不要提拔有成果的人，否则你可能不得不替换他们。

          回复

        4. 好吧，我见过不少 “盲目 “的程序员，他们只是完成了自己（非常有限的）范围内的工作，也许他们做得很好……然而整个工具就是无法运行，也没有人关心。

          我想，如果这个人指出了这样的问题，他不会受到开发团队的欢迎，但会受到管理层和用户的欢迎。

          回复

      3. >谁写的代码最多

        这就是你的问题所在。代码数量与价值无关。事实上，如果代码漏洞百出、技术债务缠身，那么代码数量就会与价值成负相关。以代码行数来衡量生产力，会严重阻碍编写整洁、可维护、无错误的代码。

        回复

        1. 从我们听到的许多人工智能 “成功 ”故事中，我也有类似的感觉。人们对人工智能在短时间内编写出多少行代码感到惊讶。

          但对于这些代码行创建后的维护和调试，人们却并不十分关心。

          回复

          1. 但代码运行得很好，每分钟能完成一百多笔交易！所有这些都只需要每天 750 美元的 AWS 实例！为那些昂贵的开发人员省了不少钱！/s

            数学留作读者练习。

            回复

        2. 使用几行方法链的组合，将 100 多行 5 个以上交织在一起的控制流混乱函数变成一个表达式，这在我看来总是一种令人愉悦的体验。

          回复

        3. >代码数量与价值并不相关。事实上，如果代码漏洞百出、技术债务缠身，那么代码数量可能与价值成负相关。

          ** “无代码 “或虚无主义软件工程 **

          没有代码比没有代码运行得更快。

          没有代码比没有代码的错误更少。

          没有代码比没有代码占用更少的内存。

          没有代码比没有代码更容易理解。

          无代码是获得安全可靠应用程序的最佳途径。什么都不写，什么都不部署。

          我最有成效的一天就是扔掉了 1000 行代码。– Ken Thompson

          最便宜、最快、最可靠的组件就是那些不存在的组件。– Gordon Bell

          删除的代码就是调试过的代码。– Jeff Sickel

          以代码行数衡量编程进度，就像以重量衡量飞机制造进度一样。– 比尔-盖茨

          * 傅大师与万行 *

          傅大师曾对一位来访的程序员说过： “一行 shell 脚本中的 Unix 特性比一万行 C 代码中的 Unix 特性还要多”。

          这位对自己精通 C 语言引以为傲的程序员说： “怎么可能？C 语言是实现 Unix 核心的语言！”

          傅大师回答说 傅大师回答说：”没错。然而，一行 shell 脚本所包含的 Unix 内核比一万行 C 语言还要多。

          程序员越说越苦恼。”但是，通过 C 语言，我们体验到了里奇教主的启迪！我们与操作系统和机器融为一体，收获了无与伦比的性能！”

          傅大师回答道： “你说的都对。但是，一行 shell 脚本中的 Unix 特性仍然比一万行 C 语言中的 Unix 特性还要多。

          程序员对傅大师嗤之以鼻，起身准备离开。但傅大师向他的学生努比点点头，后者在旁边的白板上写下了一行 shell 脚本，并说道： “程序员师傅，请考虑一下这条流水线。如果用纯 C 语言实现，岂不是要上万行？

          程序员捋着胡须喃喃自语，沉思着努比所写的内容。最后他同意是这样的。

          “那你需要多少个小时来实现和调试这个 C 程序呢？”努比问道。

          “很多，”来访的程序员承认。“但只有傻瓜才会花时间去做这件事，因为还有许多更有意义的任务在等着他。”

          “那谁更了解 Unix 的本质呢？” 傅大师问道。“是写下一万行代码的人，还是察觉到任务的空虚而不编码从而获得功绩的人呢？”

          听到这里，程序员豁然开朗。

          来源：http://www.catb.org/~esr/writings/unix-koans/ten-thousand.ht…

          回复

          2. 这是一个了不起的收藏。非常感谢。

            这正是我编写如何改进代码的幻灯片所需要的。

            回复

            1. a) 可以做成一本很好的茶几书。

              b) 可以做成一张很好的海报。

              回复

          3. Unix 天生喜欢恶意论证和代码注入漏洞，而 C 语言则带来了缓冲区溢出等一系列问题。

            回复

        4. 归根结底，代码对企业和思想者都是一种责任。花尽可能多的时间来研究如何避免编写代码并将其最小化是值得的。

          回复

      4. https://yosefk.com/blog/engineers-vs-managers-economics-vs-b…

        >……这是一个常见的故事，也是一个有趣的角度，但 “最好与足够好 “的提法忽略了一些东西。听起来好像有一条通往 “最好 “的路–通往 100% 的路。工程师们希望一直走下去，直到真正达到 100%。而管理者却强迫他们在 70% 的时候退出：

        >>在每个项目的生命周期中，都会有那么一段时间，正确的做法是枪毙工程师，然后把这个混蛋运走。

        >然而，通往 “最好 “的道路往往从一开始就与通往 “足够好 “的道路截然不同。工程师和管理者的目标不同，他们的思考方向也就不同。一个简单的例子可以说明这种差异。

        >假设有一堆计算机，人们可以在其中运行东西。需要一些系统来决定谁在何时何地运行什么。> * 工程师会希望每时每刻都有尽可能多的计算机被占用–否则就会造成浪费。

        > * 管理者会希望给每个团队配备尽可能少的计算机–否则就会造成浪费。

        > 这些方向并不完全相反–“尽可能多 “与 “尽可能少”。它们关注的重点不同。工程师想象着闲置的机器渴望工作，他希望给它们提供任务。而经理则认为，愤怒的用户渴望机器，他希望给他们提供足够多的机器，让他们安静下来。他们对 “成功 “的定义几乎没有关联，他们对 “浪费 “的定义也是如此。

        > “足够好 “并不是 “最好 “的 70%–甚至不在一个方向上。事实上，它更像是-20%：一旦部署了 “足够好 “的解决方案，通往 “最好 “的道路就会变得更加艰难。你要限制对机器的访问，让人们习惯使用 ssh 会话界面，而 “最好 “的解决方案不会提供这种功能。

        回复

      5. 这个故事与文章中的 Dilbert 漫画非常相似。除了无意。

        回复

      6. 可能不是重点，但每天提交是 TBD 的一种方法，它对提高工作效率很有帮助。但对于衡量工作效率来说就没那么有用了。

        我无法想象通过量化每天的提交来衡量开发人员的工作效率会有多痛苦。真是浪费。

        回复

      7. > 问题是这个实习生很糟糕，所以我们让他写单元测试。

        请告诉我，你们给这个人分配的是 “提高代码覆盖率 “的任务，而不是 “我写了一个新功能，给它写单元测试 “的任务

        回复

    2. 开发人员的工作效率就像量子力学。一旦你试图测量它，波函数就会坍塌，你就从根本上改变了你试图测量的东西。

      尽管如此，在我工作过的每一个地方，你都可以通过查看代码的总体提交量来了解谁是顶级开发人员。Tim sensei 的这种情况可能比我想象的更常见，但我从未遇到过。

      回复

      1. >在我工作过的每一个地方，你都可以通过查看整体代码提交来了解谁是顶级开发人员。

        这种方法适用于初级到高级职位，但如果公司里有职员以上的职位，这种方法就会很快失效。担任这些职位的工程师仍在编写代码，但他们编写的代码只有以前的一小部分，而这正是他们的职责所在–您希望这些人负责整个项目、集成和迁移的工程设计。这类工作非常重要，应该由顶级开发人员来完成，但其提交次数会比开发单个功能的人员少得多。

        除了少数源代码级复杂度较高的项目外，Staff+ 工程师的提交量与高级工程师不相上下，这很可能是级别不对或使用不当。

        回复

        1. 作为一名员工工程师，我有相当数量的提交，但按照故事点来衡量，几乎没有任何提交是关于 “功能 ”的。

          我们正在构建其他人用来更好、更快地交付功能的东西。

          回复

        2. 是啊，我一直在非技术公司工作，团队规模很小，也没有类似的职位。但任何一个拥有 Staff+ 工程师的地方都应该知道，不要试图根据某些指标将他们与更初级的开发人员相提并论。

          回复

          1. 举个例子，我曾与一位员工级软件工程师共事（我也是同一级别），他们的差异度一直是零，超过一半。

            因为他们更倾向于产品原型–事实证明他们非常适合。

            回复

      2. 我曾经参与过这样一个项目，一个平庸的开发人员却对项目充满热情。没有人会关注这样的团队动态，但他们却无处不在。

        回复

      3. 由于我对博弈论略有涉猎，我曾考虑过一些有趣的角度，比如秘密的内部指标，以及惩罚那些简单地博弈激励机制的人。例如：网络游戏中的僵尸检测和禁言。公司不能立即封禁似是而非的机器人，而是要隐藏其（不断变化的）内部算法，并一波一波地封禁。

        基本上，对待（非）生产力就像对待僵尸检测一样，笑。

        回复

        1. 几年前，我们开始追踪办公室出勤率和公关人数。管理层信誓旦旦地表示，他们了解其中的细微差别，这些指标只会用于跟进异常情况。

          但是，一位中层管理者设定了一个目标。他的同事们也不甘示弱，制定了更宏伟的目标。他们的下属也会积极跟进低于目标的人。有几个月的时间，在公司的大部分地方都隐含着 “不休假 “的政策，直到他们更新了考勤仪表板，将 PTO 计算在内。现在，如果没有非常有力的相反证据，工程师在堆栈排名中的位置被假定为她在公关计数排名中的位置。

          你概述的方法可能是最佳的，但我不认为中层管理人员作为一种文化能够做到这一点。你在仪表盘上给他们一个关键绩效指标，他们就会以一种非常开放和简单的方式来进行竞争。衡量标准是难以辩驳的，而细微差别则需要时刻保持警惕。

          回复

      4. 这不仅仅适用于开发人员的工作效率。

        回复

      5. 多亏了古德哈特定律，对于任何成为目标的衡量标准都是如此。

        回复

      6. 你可能无法通过观察来做到这一点。你可以把同一个项目交给几个开发人员，可能会发现他们在时间和质量上有很大差异。但是没有人会投入大量的工作来进行这样的评估，而且评估的真实度和持续时间（可能需要数周）都不足以让评估变得有意义。

        回复

      7. >话虽如此，在我工作过的每个地方，你都可以通过查看整体代码提交情况来了解谁是最优秀的开发人员

        是的，在我目前工作的地方，我们并不衡量编码性能指标，但如果你查看一下提交到 repo 的最高提交者（按提交次数计算），你就会看到所有能为公司带来最大价值的人。即使是员工工程师，最优秀的工程师仍然是那些能编写代码的人，尽管他们编写的代码可能不如高级工程师多。每月只提交 1 篇代码的员工工程师通常不会为公司带来价值，尤其是考虑到他们的高薪。

        回复

        1. 在我的上一份工作中，我在过去一年半的时间里一直担任员工工程师，但几乎没有提交过任何代码，因为我一直在撰写提案、向高管辩护、做架构审查、做设计咨询，以及规划大型事件的长期应对措施。我很清楚，我为公司带来了大量价值，但这些价值与提交非常不相关。我不太喜欢这样的工作，因为我需要编码，所以我又转到了一个疯狂提交的岗位。）

          回复

          1. 只要把所有的方案和设计文档都检查到源代码控制中，你还是会有很多提交的！

            回复

      8. 我喜欢查看删除的行数，以及新增的行数或 PR 数量。更有经验的人会在重构和删除旧内容的同时添加新内容，这样就能达到一定的平衡（除非在 repos 之间出售或移动文件树）

        回复

        1. 删除的行数应该是添加行数的 5 倍。我不相信任何开发人员不会从删除代码中获得快感。

          回复

      1. 我专业写代码已经有十年了，但我从未在空闲时间写过这么多代码，因为我可以直接用 vibe 编码。在工作中我不会这么做，而且我可能不会像信任自己的振动一样信任一个后辈，但没有任何工具能让我感觉如此强大。

        回复

        1. 我从未尝试过本文所述的 vibe 代码，但我能看出它的破绽所在。起初，代码可以正常工作。最后，出现了一个错误，而 LLM 无法修复它。在这个阶段，你需要独自面对一个对你来说完全陌生的可能很大的代码库。

          即使在小型项目中，有时我累了，也会让 LLM 帮我做一些重构工作或写几个测试。首先，无论 LLM 写了什么，都要经过代码审查，我不会为了让同事抱怨而提交我没有读懂的代码。其次，如果代码不起作用，就会令人沮丧。为了让 LLM 帮忙，我喜欢对我想要的东西有一个相当清晰的概念，知道 “正确的 “代码是什么样的，这样我就能给出更多的指示。

          回复

          1. 这个想法是 “重写比调试更快”，所以如果有东西坏了，就请 LLM 重写

            我不喜欢这样。

            回复

          2. 是啊，如果有时间，我完全可以自己写，所以我只是边写边改。我也会给它很多指导，告诉它我在寻找什么，但经过一些设置后，我就可以一边看电视，一边每隔几分钟检查一次。

            回复

        2. 对于原型来说，它绝对是不错的选择，但没有什么更复杂的。

          回复

          1. 我以前也这么觉得，但在过去 6 个月里，我的观点发生了很大变化。你完全可以用这种风格制作非常复杂的东西

            回复

            1. 这其实并不矛盾。

              据我所知，你可以建立非常复杂的原型。但除非这些原型可以被信任和维护，否则它们也只能是原型而已。

              回复

            2. 给我举个例子，看看只写了提示语就能得到这么复杂的东西

              回复

              1. 有时候，你进入一个代码库，它看起来就像是在试图召唤一个用意大利面条和胶带做成的洛夫克拉夫特实体。这些代码库是我见过的最糟糕也是最复杂的东西。它们肯定不能很好地工作，我甚至不确定是否能很好地召唤出旧的实体。我并不觉得 LLM 代码与那种怪东西有什么明显区别。它确实很复杂。

                回复

      2. Vibe 编码现在已经成为实际工作的一项技能要求，但幸好我想，现在还没有我想工作的地方。前几天，我看到一家 YC24 公司在 “金融服务业 “招聘 “振动编码员”。该职位的一个先决条件是，你当前的代码中至少有 50% 是由人工智能生成的；振动编码经验 “没得商量”。传统程序员无需申请。而且，你最好做好准备，每周工作 7 天，每天工作 12 小时。年薪高达 120,000 美元，外加股权，并要求搬迁到旧金山。这就像麦当劳在旧金山的钱一样，所以我猜他们认为经营一家振动编码血汗工厂能为他们省下一大笔钱。

        哦，还有最重要的一点？这家初创公司提供的 “金融服务”？代表讨债人向债务人索要钱财的自动机器人电话。

        https://www.ycombinator.com/companies/domu-technology-inc/jo…

        YC 已经进入了反派阶段。

        回复

        1. “你的入职培训就是打催债电话”。

          那么，你的人工智能债务催收初创公司是通过……让他们充当人类呼叫中心的债务催收员来招募工程师的？

          真的有人工智能吗？

          哦，但通过入职培训后，你们的振动编码工程师就会专注于通过振动编码来打造产品，对吗？

          “（你要做的是……）入职客户，与他们交谈，出差拜访他们”。

          所以，你是一个巡回销售代表。你的入职工作就是假装自己是产品，然后你就是一个旅行销售代表，一边旅行一边编写代码？

          回复

        2. 这只是一个营销噱头，就像当年拿着 20 万薪水的工程师一样。而事实上，你正在谈论这件事，并分享了公司简介的链接，这说明这个噱头是有效的。

          回复
        3.  > +3年工作经验。
[/ 预]
Ummmm..... 什么？
这好像是一个热爱反乌托邦科幻小说的人写的。喜欢的方式是，这是他们想要生活的未来。
          回复

      3. 或许在做出过于苛刻的评判之前，先给它一些时间？

        回复

        1. 自从 ChatGPT 出现以来，也许就已经有了编码的氛围……

          回复

          1. 更早。从谷歌开始，我就一直在 “氛围 ”编码–我想，只是换了个流行词而已。

            回复

    4. 说得好。现在很多地方都明显缺乏判断力，人们认为可以把判断力交给指标和数据，但这是错误的。

      回复

    5. 一家公司能否让主观上表现不佳的人在公司存续期间继续工作？比如，这个慈善机构在整体收入或利润上的加减是多少？如果所有公司都这样做呢？我们能否将慈善 “负担 “分配给所有公司，使社会变得更好？我的观点是，我甚至不知道衡量标准是好是坏，我们可能需要看看为什么我们会这样看待彼此。一艘船的船长可能有几个不是最好的水手，这对他们的心灵有那么大的冒犯吗？这是让他们上船、踏上旅程的机会。免费搭车 “的概念似乎给我们带来了严重的道德风险，但我想不通为什么。

      回复

      1. 这就是日本的做法。就业被假定为终身制。公司会玩一些游戏来淘汰表现很差的员工，但大多数人都能得到近似终身的工作。

        回复

        1. 该社会是如何学到这些的？或者说，他们是怎么知道这些的？

          回复

      2. 你会接受你的团队中有这样的免费搭车者吗？你最终会同时完成你和他的任务，但工资却一样甚至更低。既然您为团队制定了固定的预算，您还想再多分一些吗？
        我可以把简历寄到哪里？

        回复

        1. 如果我们要这样做，我们就不会随便挑选一个超出需求范围的人。所以，基本上，如果你重新考虑一下你的问题，我会在一个由 90 名普通学生组成的团队中雇用一个平均成绩 70 分的学生吗？会的。我们不会选 50 分的学生。在合理的范围内，这都是有可能的，本主题中讨论的这种情况是为了清除平均成绩为 80 分的学生（平均成绩为 95 分的班级中的免费搭车者）。
          我们需要辅导和支持 70 分的学生吗？需要。我们为什么要这么做？这对灵魂有好处。我所说的这些在商业中没有任何地位，就我们目前所关心的社会而言。

          回复

          1. 我的危险观点是，公司的目的是为员工提供生计。

            回复

            1. 也就是说，如果你在船上，我们绝对能给你找点事做。来，给该死的地图上色，把帆擦干净。我们为什么要把他们扔下船？

              回复

    6. >你想要的是衡量业务成果，但这些成果很难归功于某个特定的开发人员。
      我认为我们可以通过取消一些中间层，让开发人员每周与实际客户通话来解决这个问题。每个高级开发人员至少拥有一个客户。诸如此类。
      如果你是 B2B/SaaS 的开发人员，你要直接回答客户关于你工作的问题，这就完全不同了。没有人可以躲在背后–你的队友现在都在你的一旁，只能提供辅助性的帮助。一旦你让开发人员直接面对客户，你就有了一个简单的、布尔型的定性指标，几乎任何经理/投资人都可以支持这个指标： 客户满意吗？
      如果开发人员能让客户满意，那么他们就是在执行任务。如果客户不满意，那么就存在绩效问题。至于大部分或全部问题是否可以归咎于客户方面的阻挠者，这在游戏的高层是无关紧要的。开发人员应该帮助客户解除阻塞。提供会议和屏幕共享时间。一般来说，尽可能让自己有空。如果你能正确地做到这一点，客户很可能会注意到这一点，并为你提供一定程度的掩护（也就是说，当他们打电话给你的首席执行官时，你不会大发雷霆）。
      在现实中，你不可能注入更多的中层管理或流程来让开发人员承担更多的责任。唯一有效的办法就是让他们走出狗屁矩阵，走到客户面前。他们需要体验直接与满意的客户一起工作的感觉，然后意识到保持这种感觉是多么重要。
      这条路也恰好能解决技术行业的一系列其他弊病，最明显的就是追逐闪亮的兔子。当你对客户怀有敬畏之心时，你就不会在他们的眼皮底下用 NuSQL 引擎玩流量游戏了。

      回复

      1. lol 不，我曾与这样的公司合作过。许多开发人员都有非常特殊的性格类型，他们也从技术角度而非客户角度思考问题。这并不是什么坏事，这也是他们擅长工作的原因。
        在我工作过的最成功的公司中，都有一位优秀的产品经理，他能听取客户的意见，并与技术经理合作，平衡工作的优先级/努力程度。技术经理在做决定之前会征求团队的意见（如使用 SCRUM 会议）
        ，当人们开始不信任开发人员时，问题就会出现。当我们说实施某项工作需要 4 周或 8 周时，这是有原因的。我们了解代码。我们知道代码有多麻烦，所以我们不会误导大家。反过来说，由于糟糕的管理和意料之外的陷阱，我们被训练得给出保守的估计，因此我们试图理解承诺并超额完成。如果管理层能认识到这一点，那么大家都会很高兴，前提是他们认识到 8 周的时间安排没有问题，而且他们不会向客户承诺不同的事情，并相信开发人员会做好自己的事情。
        编辑：管理者还往往忘记，我们不是工厂里的机器。我们有好的一天，也有坏的一天，还有介于两者之间的一切。我们善于用脑，但我们的大脑也会因为睡眠不足、抑郁和其他原因而受到影响。我觉得这种情况在我们身上更明显，因为我们比其他行业的人更依赖大脑。不管是在家里还是在办公室工作，即使是办公室里的噪音也会影响工作效率。
        现在，我已经开始想念离线工作了。希望能尽快回去。目前失业。

        回复

        1. 如果农作物成熟时就犁到地里，而不用费心去做收获、提炼、包装和分发给客户的所有工作，那么耕作就会非常有效。
          但幸运的是，软件开发人员并不参与农作的架构设计。
          我想说的是，为开发而开发是完全没有意义的。软件的目的是为现实世界提供帮助。每个开发人员都应该明白这一点，无论他们多么害羞或反社会。

          回复

    7. 我不认为生产率本身是荒谬的，但它绝对是一件很难做到的事，尤其是在时间间隔较短的情况下。
      我认为衡量员工的绩效很重要，你完全可以宏观地看一下，说 “你在过去一年里完成了什么”，这可以用交付 “T恤衫 “大小的项目来衡量

      回复

    8. 编程团队中的每个人都知道谁是好程序员，谁是不好的程序员。

      回复

      1. 但这种说法毫无意义。即使他们知道，我也不确定在一般情况下是否属实，因为你必须自己很优秀才能知道谁是真正优秀的程序员，反正他们也不会告诉你。

        回复

        1. 在我工作过的每个组织里，每个人都知道谁是有生产力的人，谁是没有生产力的人。
          就像在学校一样。每个人都知道谁是好老师，谁是好学生。
          我真不明白，你怎么能在与他人共事时却毫无察觉。

          回复

    9. 这并不荒谬。从管理者的角度来看，当他们决定让某人离职或晋升时，往往需要一些论据。而软件是看不见摸不着的，因此除了 “感觉 “之外，往往很难直接说出谁表现得过好或不好，以及你为什么这么认为。衡量一些相关指标可以加强你的论据和/或对情况的概述。
      我不认为该博客提出了令人信服的论点，说明衡量工作效率本身是不好的。它提出了一个令人信服的论点，即不应该盲目解读指标，但在这个案例中，指标发现了一个人在做一些不寻常的事情，经理们设法解读了为什么会出现这种情况。但是，如果这是一个应该完成任务的集成电路，或者如果你不想让 “蒂姆 “把时间花在指导员工上，那么这仍然是有价值的信息。

      回复

      1. 我认为，对个人贡献进行推理并不荒谬，只是要注重用指标来衡量。我也做过管理方面的工作，虽然我承认我更像是一名集成电路工程师。但我认为，应该通过描述个人所做的贡献以及为什么这种贡献很重要，来逐级提升业务价值。
        例如，我会这样说 X 值得晋升，因为他们的工作对按时交付项目 A 非常重要。项目 A 是困难的，但也是值得的，因为它让我们作为一家企业实现了目标 1 和目标 2。
        尽管如此，我主要在小型组织工作。我从未遇到过这样的情况，即经理远离团队，需要一种代理指标来指导他们把注意力集中在哪里，以了解团队成员每天在做什么。我认为随着公司的发展，这样做会变得越来越困难。

        回复

    10. 我认为这并不是说我们_不能_准确衡量开发人员的价值/生产力，而是说用我们现有的任何方法都无法做到这一点。正如你所说，我们不是在变魔术，因此我们的价值是可以衡量的。只是衡量需要大量的时间和精力，这不切实际。

      回复
    11.  >在我看来，衡量开发人员个人生产力的想法有点荒谬。

      在很多情况下，这样做都是荒谬的。就在前几天[0]，我们在 “价值 “衡量方面也发生了类似的故事。我认为，官僚主义已经大行其道，人们为了衡量而衡量，而不是认识到这些东西都是代用指标，你需要小心谨慎，确保你的代用指标与你想要衡量的实际事物保持一致。

      在研究和学术界，你会看到这种情况，人们试图用论文数量/引用次数/途径/新颖性来衡量。在职场中，你会看到代码行数、故事点和其他废话。人们对金钱的看法也是如此。想想看，一个月一百万美元意味着什么？

      问题在于，我们建立了评分系统，人们认为最终目标是最大限度地提高分数。分数是否有实际意义并不重要，但我们肯定会热情洋溢地争论分数是否有实际意义。更多内容请参考我对 [0] 的评论[1]。

      我一直把这个概念叫做 古德哈特的地狱

      事实上，每个系统都有噪音。我完全理解想要去除系统中所有可能存在的噪音的想法，但到了一定程度之后，试图去除噪音的做法实际上是在忽略噪音。也许问题在于，人们没有认识到随机性本身就是对不确定性的测量。没有一种测量设备是没有不确定性的。拥抱噪音。尽可能地消除噪音，但也要接受无法消除的噪音。忽略噪音会制造更多噪音。

      [0] https://news.ycombinator.com/item?id=43447616

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

      回复

  2. 他可以要求他的队友这么做，他们很乐意这么做，或者，好心的队友通常会在票据上写上 “在 @Tim 的帮助下解决了这个问题”。

    生产率指标并非完全没有价值。例如，如果我来到一个团队，看到他们大约每 1 张 Jira 单子就有 1 份 PR，而我看到一个 3 人团队中的一个人在一年中完成了 70% 的 PR，这并不是一个无知的信息。

    回复

    1. >管理部门只需将蒂姆的名字附在他可能帮忙的任何门票上，就能解决这个问题。

      我认为这根本无法解决问题。事实上，这样做会让问题变得更糟，因为 a) 你承认这个指标很糟糕，不能反映工作情况；b) 你选择保留这个狗屁指标，但却试图操纵它来提高某种情况下的得分。无论从哪个角度看，这都不是可取的结果。

      最终，你会建立起这样一个系统：参与其中的每个人都知道这是一个骗局，但却因为投入过多而不断博弈。

      回复

      1. 我认为没有人说这是一个好的解决方案。这只是众多弊端中的一个，因为这就是我们所拥有的。例如，我管理一个远程团队已经有 8 年左右的时间了，我一直在恳求大家在公共频道进行对话。其中一个原因就是想看看谁花了很多时间来帮忙。你猜怎么着，开发人员拒绝这么做。那我该怎么办？

        我有一个人，我很怀疑他没做什么工作，而且基本上是通过其他团队成员轮流帮助他摆脱困境。他不是个坏人，但可能达不到我们的标准。你说问问别人就知道了？很多文化都不允许别人说同事的坏话，即使这样做有助于改善团队。

        我并不主张任何一种解决方案，因为我不知道有什么神奇的解决方案。如果你有比世界上每个人都想出的更好的衡量标准或管理技巧，我本人和许多其他人都很乐意采用这些方法。

        回复

        1. 听起来你和团队之间既缺乏信任又缺乏沟通。

          >如果你有比世界上每个人都想出的更好的衡量标准或管理技能，我本人和许多其他人都会很乐意采用这些方法。

          哦，天哪……

          编辑：一个问题可能是他们担心坏消息会导致膝跳反应，从而使他们或他们的队友被解雇。遇到问题时，他们应该坦然面对，公开讨论，而不必担心受到影响。事实上，我认为这是团队的主要优势之一；汇集集体知识和能力。如果人们害怕坦诚交流，那么团队的表现就会受到影响。在我看来，管理者最有能力解决这个问题……

          回复

        2. 听起来，你的员工似乎认为，在你能看到的地方与你交流或相互交流，会让他们的朋友下岗或在没有建议的情况下做出错误的决定。如果你能找到一个善于建立信任和关系的人，你可能会想在你和他们之间设置一层管理层。

          回复

          1. 我认为在这种情况下，一个称职的技术负责人也会创造奇迹;)

            回复

        3. 首先–请不要被下面的评论冒犯，我的评论没有任何恶意，只是想引导您以正确的心态对待您所描述的问题。从你的公开资料来看，你似乎并没有太多的实践技术背景，我怀疑你是根据某种Scrum/敏捷技术来管理你的团队的。我想，这可以纯粹用于项目交付。但是，要深入分析团队的工作效率，问题在于你不具备必要的能力来验证你的怀疑，即团队中的某个人没有完成工作，或者是在敷衍其他人等等。只有两种方法可以解决这个问题。要么在团队中聘用（或提拔）一名技术主管，让他来做决定；要么你自己学习编程，积累至少一年的实际技术经验，然后尝试进行评估。我之所以这么说，是因为我见过背景与你类似的人通常都很纠结，因为他们试图根据各种代理措施来推断工程师的工作效率，比如谁在聊天中说得最多，谁的提交次数最多，甚至根据 Confluence 中的活动来推断。我建议任何一个 Scrum Master/PO/ 敏捷教练/MBA 思考这个难题的方法是：如果没有类似的背景、经验和能力，你就无法判断一个医生、律师或机械工程师的工作质量。那么，你凭什么认为可以在没有同样前提条件的情况下评估软件工程师呢？

          回复

          1. 我认为其他很多评论都是在胡乱假设，导致回应与现实不符。实际上，你的回答是绝对正确的。我完全同意这个解决方案。唯一不同的是，我一直在尝试从内部提拔技术主管，而不是从外部招聘。我想让团队知道，我们重视他们的贡献，而且我们会尽一切努力在内部晋升。在这一点上，我在内部遇到了与资历、语言技能等有关的各种挑战，但我正在努力解决这些问题。

            但与此同时，我还有一个团队要管理。

            回复

          2. 团队中的一名成员几乎什么都不做，靠不断请别人帮忙完成工作来维持生计。这降低了其他员工的工作效率。

            这在许多工作中都是众所周知的典型，不仅仅是编程。

            然而，我们会得到这样的评论：

            >你没有必要的能力来证实你对其中一个人没有完成工作的怀疑，而只是靠别人的帮助

            哇。

            在其他任何工作中，经理和人力资源部门都会阅读你的聊天记录、电子邮件，并要求记录通话内容–你猜怎么着？你猜怎么着？而且是以一种非常隐蔽的方式。

            另外，上述问题就像管理 101？虽然你一直在说 “没有技术能力”，但你似乎没有任何管理能力。

            此外，开发人员之间相互保持专业水准的敏捷理念也是一个美好的童话（就像整个敏捷一般）。

            回复

        4. 将生产率指标正规化并不能帮你解决任何问题。而且我敢肯定，你提到的那个人学会玩弄这个指标的速度会比其他开发人员学会适应它的速度更快。

          回复

        5. > “我一直在求大家在公共频道进行对话… 你猜怎么着，开发人员拒绝这么做”。

          所以，别再乞求了。管理者的指令是命令，而不是讨好式的请求。另外，不要再让你的下属拒绝你。他们是你的下属，你在批准他们的钱，如果他们不尽职，你可以改变他们。开除一个无视政策的人，他们的态度就会改变。

          在技术方面，明确你希望所有的项目交流都被记录下来，并且可以搜索，以便入职和自动生成文档，以及识别技术热点，在这些方面投资重构可以节省团队的时间。无论如何。如果你想监视每一个人，这不是个好办法。如果有价值，就去做。

          > “许多文化不允许有人说同事的坏话”

          在任何文化背景下，尤其是跨文化背景下，管理者的任务都是了解这些文化敏感性，然后务实地绕开它们。您已经发现了一个问题。> “如果你的衡量标准或管理技能比世界上每个人都想出的更好”

          这种态度对于找到真正的答案毫无益处，而且可能会混淆问题。

          很多人都想出了比本地应用程序所建议的更好的衡量标准和管理技能。我们缺少的不是那些高深莫测的东西，而是最基本的东西。

          回复

          1. >开除一个无视政策的人，他们的态度就会改变。

            是啊，第二天他们就会开始更新简历，并向他们的网络发出邀请。

            回复

          2. 抱着这种态度，你将培养出一支非常特殊的团队。根据你的指标，他们的工作效率会很高，忠诚度很高，而且对不合群的人很有杀伤力。但是，如果你需要创新，$diety 会帮助你。

            回复

          3. 因为提供解决方案而被降权，真是可悲。

            回复

        6. 无意冒犯，但这听起来像是你妄下结论（你甚至无法证明），并试图改变流程，从而可以钉死这个可怜的家伙。

          你的目的是什么？我希望能让球队表现出色。你能通过找茬达到这个目的吗？当然不能。其他人会保护他，因为他们知道自己将是下一个目标。你认为 “表现不佳者”（如果他真的表现不佳）是因为懒惰吗？一直寻求帮助比仅仅做一件事更困难。

          不如你想办法帮助他达到别人的水平？这才是你的目标。与其监视他们，不如奖励那些帮助别人的队员，这样他们就不会觉得有必要躲起来。让弱小的成员感到安全。目前，在承认任何问题方面，听起来环境是相当有毒的。

          如果在付出了所有真诚的努力之后，你还是失败了，需要放手让他离开，因为他确实降低了团队的工作效率，而你又无法促使他改变，那么你应该知道，这主要还是你自己的失败。没关系，每个人都有失败的时候。但这是一个信号，告诉你应该更加努力。

          (作为一个因为自己不够好而不得不让别人离开的人……在两个不同的场合……所以我不做任何评判）

          回复

        7. >例如，我管理一个远程团队已经有 8 年左右的时间了，我一直在求大家在公共频道进行对话。

          没有人这么做，因为在频道里说废话会扰乱大家。这还会让对话变成 “骑车对话”，拖累整个讨论。

          小型特设小组可以非常有效地解决问题。

          1. 小组越亲密，对话中的摩擦就越少。不需要/不希望把所有事情都说成 “公事公办”，这样就不会伤害别人的感情。

          2. 如果没有非技术参与者，小组就不需要为技术含量较低的参与者降低对话的难度。

          3. 3. 私人聊天意味着没有人会在对话中要求更新一些无用的状态。问题要么已经解决并得到解决，要么小组仍在工作。

          回复

      2. 我曾在一个组织中管理过一个团队，该团队大量使用 Jira 来衡量工作速度，让所有贡献者记录工作票据上的时间，即使他们只是提供支持，实际上也有很大帮助：

        1. 它允许进行更准确的估算（即这不是一个需要多天完成的任务，而是一个需要多人完成的任务）

        2. 它显示了知识转移的发生地

        3. 3. 它显示了人们的忙碌程度，这意味着我们一开始就做出了准确的估算。

        我确实认为敏捷会变得过于规范。但是，如果你碰巧工作的公司就是这样的公司，你就不可能推倒重来。因此，让多个参与者针对同一份工作记录他们的努力，就能让团队以更有机的方式运作，尽管有更严格的Scrum动态的僵化结构。

        或者换句话说：有时你无法完全改变系统，所以你的下一个最佳选择就是调整它，让它至少更好地为你工作。这就是 GP 建议所要达到的目的。

        回复

      3. 虽然用数字来衡量生产率可能行不通，但我认为全科医生只是在记录贡献。

        我喜欢这种方法。现在你不仅可以有同行的建议，还可以有实实在在的记录。

        回复

        1. 在大型组织中，我看到有人通过这种方式悄然晋升，即使非技术或人手不足的管理团队可能难以看到他们的直接贡献，但他们的工作成效有目共睹。这是一项基本的生存技能，而不在于一开始是否正确–我经常驾驭这些系统，因为我必须这样做。

          ，当然会有人玩弄系统，但同行往往会意识到那里发生了什么，这就是管理问题了。

          回复

      4. 在这一点上，Bug/案例跟踪更像是垃圾。我用过的所有系统都只支持一个受让人，所以即使是在平等的结对编程中，你也必须选择谁正式获得案例。

        他们建议的是围绕案例跟踪器开展工作，而不是围绕度量标准。

        回复

      5. 在公司或任何业务中，你都需要交付一些东西，如果你得到了 X 金额的报酬，付款人需要知道他们得到了一些回报，他们问本周做了什么并不是管理问题。

        回复

      6. > 这实际上使问题变得更糟，因为 a) 你承认度量标准是狗屎，不能反映工作

        ，这就像物理学一样： “所有模型都是错的，有些模型是有用的。所有指标都是错的，但有些指标在正确应用时是有用的。

        回复

    2. 这就是为什么有些人在提交中自动测试失败后，坚持要你把他们的名字附在你的票据上（或者更好的办法是自己做）。”坚持不懈地指导团队成员培养质量文化 “等等。

      回复

      1. 没错。如果你不考虑人们会如何玩弄系统，那你就有麻烦了。像这样的小修正为游戏规则开辟了其他可能性，现在人们会为自己的贡献是否足够好而争论不休。

        回复

    3. 事实上，我很震惊蒂姆本人在明知这个指标存在并将被用于解雇决定的情况下，没有在一开始就把自己加入到所有这些票据中。这简直就是缺乏自我保护意识。在我所见过的任何一个以某种指标衡量业绩的地方，每个人都会本能地试图自己去提升那个指标。不需要其他动机。

      回复

      1. 并非所有人都会玩指标游戏。

        有些人只会觉得这些指标愚蠢而令人沮丧，从而回避它们。(

        有些人认为这种情况会慢慢消失，或者他们的经理会为他们打掩护。(正如文章中最终发生的那样。）

        有些人与经理+高管+人力资源部门进行幕后谈判，以结束糟糕的指标。

        有的人则会用强烈的不赞同的眼神融化指标。(管理建议：这种意志力更适合用来解决业务和工程问题）。

        回复

        1. 是的，我没有玩衡量标准游戏，我被烧伤了，因为我的衡量标准在玩游戏的同事面前显得不那么好。代价是，当 “你的指标告诉我们你做得不够好 “的话题出现时，你不得不提醒大家你到底完成了多少工作，你到底为团队提供了多少支持。

          回复

          1. 我已经接受了现实，每个雇主在这方面基本上都是一样的。你需要把 25-50% 的时间花在实际工作上，50-75% 的时间花在政治、自我推销和追逐指标的工作上，这样你才能 “展示你的影响力”，或者不管你的公司怎么说。我的每一份工作都是这种情况。如果你只是以专家的身份进入公司，百分之百地完成你受雇完成的技术工作，那么你的职业生涯会很糟糕。

            回复

            1. >在这方面，每个雇主基本上都是一样的。

              事实并非如此。至少我在欧洲工作过的公司不是这样。

              回复

      2. 蒂姆可能意识到，如果他试图获得他帮助获得的机票，他最终可能只获得 30%-50%。如果他从不要求赊账，但又被人看到一直在工作，人们就会把零夸大到令人产生幻觉的生产率水平。

        回复

      3. 这是一种与个性和文化密切相关的现象。很多人会，但也有很多人不会。

        当你拥有政治权力时，指出不玩游戏往往是指出人们正在接受评估的系统中存在的问题的最有效方法。在某些情况下，这也是非常明智之举。

        回复

      4. 玩游戏，任何数量的管理层混蛋都会把他们自己扛在你的肩上。除非你对这种事情感兴趣，否则就不要妄加评论。

        回复

    4. 这在自动化指标中是行不通的，谁分配到工作项目，谁就能得到所有的分数。

      回复

    5. 啊，”昆汀-塔伦蒂诺呈现 “模式。不错。

      回复

    6. 在足球比赛中，你不仅要追踪进球者，还要追踪助攻者（将球传给进球者的人）。这仍然不能涵盖所有的贡献，但也许这是为蒂姆案创造更多透明度的一种方法？

      回复

    7. 你说得很对，但有些人就是不愿意玩愚蠢的游戏。奇怪的是，主教练从未与球队共处一室，也不了解球队的动态。从疑点出发，他肯定是新来的，但任何一个有水平的主教练都会问队员们球队的动态是怎样的。

      回复

      1. 我的理解是，像这样度量化是经理们向上层管理者为 “表现不佳 “的团队成员辩护的一种有形方式。你的经理可以随时说你是团队中有价值的成员，这当然会有很大帮助，但如果你的经理能说：XYZ 是团队中有价值的成员，如果你需要证据，他们在支持性角色上提供了很多价值，比如在这些票据上，这就更有说服力了。[列出票据]。

        回复

      2. 同意愚蠢游戏的说法，但这只是对他人贡献的认可。我认为这应该得到普遍鼓励，无论是否有衡量标准

        回复

        1. 我同意。我认为经理仅凭指标就准备解雇他是非常荒谬的。有句话我要不伦不类地套用一下，”当你可以衡量某件事情时，那就是唯一重要的事情”。

          至少他先询问了作者的意见。

          说了这么多，如果他自告奋勇要做其他开发人员的导师，自己却不做任何测试，那就有点奇怪了，除非他的角色是经过明确决定/沟通的。我认为这样的角色应该是一半时间指导，一半时间处理问题单，但我对团队的了解不够，无法判断。就像我说的，我假设经理是新加入球队的。

          回复

    8. 在这里，”琐碎 “和 “固定 “都做了令人难以置信的繁重工作。

      回复

    9. 这一点很有意思。在我的印象中，我从未见过可以将一张票分配给多人的票务系统。

      回复

      1. 在我使用过的一个系统中，每张票单都有一个 “受让人”（负责大部分工作）、一个 “技术负责人”（了解情况并能提供状态和指导）和一个 “执行所有人”（如果需要，你可以将票单上报给他）。我怀疑这些都是自定义字段，如果需要，还可以进一步扩展模式。

        回复

  3. 很高兴听到蒂姆留下来了，而且作者设法将整个流程引向正确的方向。这需要一个善于倾听的管理者。

    我经历过这种生产力指标涓滴效应的 “坏结局”： OKR。这家初创公司不仅要求团队每 3 个月进行一次目标关键成果审查，还要求个人也进行一次审查，此外，还将股票期权与 OKR 挂钩。这是一家机器人初创公司，团队跨领域（软件、硬件、嵌入式、DevOps、硬件设计、硬件测试、硬件维护等等等等）。

    结果如何？开发人员成了孤岛。再也没有 “蒂姆 “了。当我（软件集成商）遇到一个问题时，虽然我无法解决，但直觉这一定是一个根深蒂固的问题，于是我向专家（控制/运动学）寻求反馈。我得到的答复是：”很抱歉，我真的很想帮你，但我的 OKR 截止日期已经很近了，我根本没有时间”。他本可以在一天或更短的时间内解决这个问题，但最终却花了两周时间。

    问题原来很严重：在一层又一层的 C++ 巨型 monorepo 中，我发现 boost 库和一个自定义的运动学库有隐式结构拷贝，不同的库（两个以上）使用不同的顺序来表示平移和amp；旋转（xyz、rpy、Euler、Quaternion）和每个组件的所有顺序都不同。不知何故，在两年的运行过程中，没有人为此感到困扰，直到我们的新团队不得不使用它。

    我曾向软件团队报告过这个问题，但同样因为 OKR 的原因，没有采取任何措施。

    回复

    1. 我认为，正因为这家初创公司搞砸了 OKR，所以 OKR 还是很有意义的。

      英特尔和谷歌在它们的成长期显然非常依赖OKR。但是：

      – 它们应该是层层递进的（所以部门之间不应该发生冲突的 OKRs）

      – 你永远都不应该把它们与个人绩效结果/报酬/奖励挂钩

      回复

      1. 我的感觉是，OKRs 在英特尔和谷歌都是后来才出现的。你知道它们大约是从哪一年/多大开始实施的吗？

        我曾与一位前谷歌员工共事，他曾试图让我们使用 OKRs。这完全行不通。公司规模较大。

        就像很多事情一样，我并不认为OKR一定是个坏主意，只是好主意总是输给文化。有了正确的文化/领导力，过程并不重要。也就是说，OKRs 并不能解决组织不协调的问题，反之，有无数种其他方法可以让组织与正确的文化和领导力保持一致。因此，在实践中，就像其他事情一样，它最终只会让事情变得更糟，因为它永远不会真正解决问题。

        回复

        1. 谷歌在不到50人的时候就开始使用okrs，因为董事会成员中有一位是英特尔的老员工。早年的情况我不太清楚，因为很遗憾我当时并不在那里，但在 2011 年加入时，我对 okr 流程的印象是，它完全是一派胡言，极大地浪费了每个人的时间。我知道 google+ 的 okr 流程进展顺利……

          回复

    2. 100%如此。想牺牲团队产出？让团队成员关注个人目标。团队的一致性和同步性会影响该团队的工作效率和效果。

      回复

  4. 我同意其他几位的意见 — 这是一种奇怪的模式，一个程序员不做任何个人工作，却做了所有的帮助工作。

    在我看来，更健康的情况是蒂姆像其他人一样做故事，而当人们需要帮助时，他们会向小组请求，谁在这方面做得最好，谁就会帮助他们–或者谁已经很久没有帮助过他们了。

    当然，对于那些最需要帮助的人来说，有更容易的故事，蒂姆应该一个人承担最难的故事？

    又或者，如果你真的有一个一边倒的团队，每个人都是直接从学校毕业，没有任何经验，只有一个超级资深的开发人员，那么……他们难道不应该是一种特殊的团队领导者，全职指导工作，而不受衡量标准的限制吗？

    这里的帖子完全不是一个衡量标准无法捕捉工作的好例子。实际上，它所反映的事实是，要么蒂姆的职位名称和衡量标准对他个人来说是完全错误的，要么蒂姆没有贡献出最难的代码，而团队也没有分配好 “帮助 “他的工作量。在这两种情况下，衡量标准都是按照预期工作的，而且它暴露出了一些非常重要而需要解决的问题。(记住，”炒掉 Tim “并不是你可以根据指标采取的唯一行动）。

    回复

    1. >当人们需要帮助时，他们会向小组询问，谁在这方面做得最好，谁就会帮助他们，或者谁已经很久没有帮助过他们了。

      我同意这对一个组织来说是健康的，但我认为这往往是不可能的。在这个例子中，组织显然没有跟踪导师的活动。因此，任何帮助过别人的人都得不到认可。

      我曾与很多人共事过，他们认为 “无情地确定优先次序 ”是一种优秀品质。这意味着没有人会得到任何帮助。只有索取。没有给予。真的是纯粹的自私。

      回到这个例子。蒂姆挺身而出，填补了公司的一大空白。人们需要帮助。他决定反其道而行之，提供帮助。然而，他并没有在领导的帮助下这样做，而是一味地做该做的事，结果差点丢了饭碗。

      坦率地说，我很认同蒂姆的做法。我喜欢帮助别人解决问题。无论是构建环境问题、测试失败还是设计缺陷。我经常在工作之余帮助别人。虽然我的直接经理知道这一点，而且也能接受，但上层领导并不在意，他们只希望每个人都表现出自己的工作比同事的工作更重要的样子。不分轻重缓急的做法是有毒的种子。

      我有点跑题了……如果不跟踪帮助情况，也不给予奖励或鼓励，如何鼓励帮助同伴和下级？尽管有各种指标，如何保持健康的文化？

      回复

    2. >难道不应该让他们成为一种特殊的团队领导，全职指导而不受指标的限制吗？

      听起来情况正是如此，作者所在的公司在看到这些数据后也确实采取了这样的措施。那么，你的抱怨是什么呢？

      回复

  5. 蒂姆是被聘为教师还是培训师？我觉得奇怪的是，听起来蒂姆并没有做任何个人工作。

    作为一名非常有经验的程序员，我确信我可以通过整天与其他程序员结对来提高他们的工作效率。然而，这真的是对我的时间最好、最有效的利用吗？据我估计，如果我将大约 20% 的时间用于与他人配对，80% 的时间用于个人贡献，那么团队的整体工作效率将达到最高。(文章说蒂姆很有 “耐心”，但也许他太有耐心了，浪费了很多本可以用来做其他事情的时间。

    回复

    1. 我曾经担任过一个由 5 名新毕业生组成的团队的 TL。实际上，我所有的时间都花在了教他们如何解决问题、修复（防止）他们代码中的错误以防被提交、编写模板或永远不会被列入故事点的下层代码上。但是，我将他们的职责限制在一种格式和结构中，这样他们就不会每隔一周就重写彼此的代码了。

      我喜欢教书，所以对我来说，这样度过一天要比喝着咖啡因、写着团队其他人无法理解的代码愉快得多。我加入那个团队是因为他们经常错过最后期限。当我离开那个团队时，他们终于提前完成了任务，但更重要的是，他们有了一个大家都能理解的代码库。如果我自己编写所有的代码，就不会有这样的结果。我喜欢告诉自己，如果我一个人编写 80% 的代码，就能让团队提前完成任务。但不管是不是真的，当我离开的时候，我都没有信心在没有我的情况下团队还能继续下去。

      我是否可以花更多时间编写代码？也许可以，但什么能带来最大的商业价值呢？我是作为一名光荣的软件工程师受雇的，但与其说我交付的是代码，不如说我交付的是一支能编写代码的团队。他们的经理永远不会这么做。那么，我应该优先考虑做我的职位所要求的事情呢？还是做对长期任务最有利的事？每个人的情况都不一样，如果教导对你来说是一种心灵上的折磨，或者更重要的是，团队拒绝接受教导，我建议你还是直接交付代码吧。在这种情况下，每个人都想学习，所以这是最简单的途径。

      回复

      1. >一个由 5 名刚毕业的大学生组成的团队

        >他们经常错过最后期限

        ，天哪，真想不到。

        >我喜欢告诉自己，如果我一个人编写 80% 的代码，我就能让团队提前完成任务。

        >什么能带来最大的商业价值？

        公司应该做的是雇用你和一个新毕业的学生（而不是五个），你可以指导他们，而不用把所有的时间都花在指导上，这样就可以用更少的钱完成两个人的工作量。

        回复

        1. 在这个世界上，事情总是尽可能地顺利进行，来自这个世界的建议价值有限。

          回复

        2. 从外部来看，我们似乎很难说这笔交易对他们的结局如何。他们花费了经验丰富的程序员的时间来组建一个五人团队。如果他们让 GP 培训一个人并同时编写代码，他们就会有一个优秀的新工程师和一些代码。现在他们有了五个优秀的新工程师。

          我的意思是，这要看花了多长时间，GP 在此期间能编写出多少代码，以及经验教训的粘性有多大。当然，我们有理由相信 GP 是正确的，这对公司来说是一笔不错的交易。

          回复

          1. 这家特殊的公司支付了远远低于市场价的薪水，并承诺提供有趣的工作。毫无疑问，这是在鼓励雇用刚毕业的学生，你可以掷骰子，希望优秀的学生会留下来，因为他们喜欢这份工作。他们提供的薪水很难吸引专家。

            回复

            1. 呀。我还想说的是，这是你的轶事，从技术上讲，你有可能错，也有可能对，但我们与基本现实没有任何联系，无法反驳你的解释……所以，为什么不顺着你的故事走呢？

              回复

        3. 是的，公司应该做的是只雇用专家！雇用刚毕业的大学生绝对是他们犯的一个错误！

          …except then I never would have been willing to work there. 我不会为一个 MBA 打杂的工作。我想为一家愿意投资于人的公司工作。这样的公司不会把生活当作一场零和游戏，为了让公司赚钱，就必须让别人吃亏。

          我明白，对大多数人来说，图表上的线必须向上！而且必须一直向上，直到永远！但我拒绝接受这种说法，因为它是导致现实被 “石化 ”的直接原因，我拒绝玩任何负和游戏。”唯一的制胜之道….”，诸如此类。

          顺便说一句，如果只有两个人的团队，那个项目早就夭折了，因为我最终还是离开了那家公司。所以，这个建议会让项目夭折。系统恢复能力也很重要。

          编辑：

          >哎呀，想不到吧。

          这不是必然的。如果他们的经理像我一样善于教授和理解代码，他们就不应该错过最后期限。事实证明，我承认我并没有贡献多少代码行。这到底是什么意思？刚毕业的大学生都是坏人？

          回复

          1. >是的，公司应该做的是只雇用专家！

            我没这么说，你也知道： “

            >我不会为一个 MBA 打杂的工作。我想为愿意投资于人的公司工作。

            嗯，在我看来，一个雇佣了 5 个应届毕业生的人听起来就像一个 MBA 管理员，而不是一个愿意投资于人的人。>顺便说一句，如果只有两个人的团队，那个项目早就夭折了，因为我最终还是离开了那家公司。所以，这个建议会让项目夭折。系统恢复能力也很重要。

            你不能被替代，因为……为什么？因为有人离开，有人被雇佣。生活还要继续。新毕业的学生也可能离开。

            回复

            1. >嗯，在我看来，雇用 5 名新毕业生的人听起来像是 MBA 的豆子计数器，而不是愿意投资于人的人。听起来，他们请来一个经验丰富的程序员（你），只是因为之前存在的病态团队（可以预见的）失败了。

              不，这是我跳级后的一个宠物项目，我是在他向我的上司寻求解决延迟问题的办法后加入的。拥有这个项目的经理让他手下所有经验丰富的程序员按直接合同工作。

              这家公司有很多合同都规定了分配的工程时数。这是一个内部项目，没有硬性的工时上限，之所以分配这些工时，是因为如果不这样做，就会有不当行为。这在很大程度上是一个利用现有资源组建的团队，而不是刻意只选择新毕业的学生。

              我不能被替换，因为这是一个内部项目，一旦没有积极的开发，它就会被扼杀。而且我怀疑内部政治因素也会阻碍它在第一次延迟/失败后重新启动。事实证明，事情远比人们喜欢做的简单假设要复杂得多。

              >听起来，他们请来一位经验丰富的程序员（你），只是因为之前存在的病态团队（可预见的）失败了。

              预测失败比预测成功更容易。不过，这也是一种零和或负和游戏。这通常是一种廉价的自我优越感，而不是去做更难的事情。不过我之前的编辑已经解决了这个问题。失败其实并不像你想预测的那样是必然的。

              编辑：

              >我没这么说，你也知道： “公司应该做的是雇用你和一个新毕业生（而不是五个）”。

              没错，我当然知道你没这么说，我也不认为你真的会主张这么做。但把一件事推向极端，看看它的失败之处，是一种有用的修辞工具。问题的关键在于，只雇用专家显然是不好的，这和只雇用刚毕业的大学生是不好的道理是一样的。

              我想我们都同意需要取得平衡吧？

              我认为 5 个新手对 1 个专家是好的，就像 5 对 0 是坏的，就像 1 对 1 是坏的。问题的关键在于，并不存在一个是对，另一个是错的神奇界限。这支队伍在添加了缺失的拼图块后就没有问题了。而且，它还取得了 “1 对 1 ”无法取得的成功。在描述一个你无法看到大部分拼图的拼图时，没有合理的方式来描述 “你应该怎么做”。

              回复

              1. >它们之所以被指定，是因为如果不这样做，就会是渎职行为。

                我不明白这是什么意思。

                >这在很大程度上是一个根据现有资源组建的团队，而不是刻意只挑选新毕业的学生。

                然而，你的另一条评论却说：”这家公司以低于市场价的薪酬，承诺提供有趣的工作。毫无疑问，这是在鼓励雇用刚毕业的学生，你可以掷骰子，希望优秀的学生会留下来，因为他们喜欢这份工作。他们提供的薪水很难吸引专家。” https://news.ycombinator.com/item?id=43453700

                >作为一个内部项目，一旦没有积极的开发，它就会被扼杀。

                我很难理解为什么这个项目需要存在。

                >但把一件事情推向极端，看看它失败的地方，是一种很有用的修辞工具。

                我不同意，在这种情况下，这只会引起不必要的争论。无论如何，你最后不得不收回并澄清：

                >我认为 5 个新手对 1 个专家是好的，就像 5 对 0 是坏的一样

                但团队是 5 对 0。

                >就像 1 对 1 是坏的一样。为什么？

                回复

                1. > 我不明白这是什么意思。

                  意思是说，这个团队在很大程度上是利用现有资源建立起来的，因为公司现有的专家本可以指导新毕业的学生，但他们已经在全职工作，做着与公司有直接合同义务的事情。如果我把他们从现有的正在进行的合同中抽调出来指导新手，那就是我的疏忽，而且合同对工作时数（而不是工作年限）有硬性限制，因此把新毕业的学生放在这些合同中，取代有经验的工程师，会降低合同的成功率。

                  >然而，你的另一条评论却说：”这家公司以低于市场价的价格支付报酬，并承诺提供有趣的工作。毫无疑问，这是在鼓励雇用刚毕业的学生，你可以掷骰子，希望优秀的学生会留下来，因为他们喜欢这份工作。他们提供的薪水很难吸引专家。” https://news.ycombinator.com/item?id=43453700

                  没错，这两种说法并不冲突。>我很难理解为什么这个项目需要存在。

                  嗯，因为这是一个非常酷的项目，公司最终确实把它推销给了不同的客户。>我不同意，在这种情况下，这只会引起不必要的争论。无论如何，你最后都不得不收回并澄清：

                  我没有收回任何东西？争论不好吗？事实上，我很喜欢争论有趣的观点和话题。如果你愿意犯错，你就能学到东西。举个例子，我并不认为我之前举的例子有什么争议。我也不记得基于合同的工程工作并不是一件常见的事情，大多数人已经有了直觉。

                  >[就像5比0是不好的……]但这个团队是5比0。

                  你说的病态团队？是的，很糟糕 错过最后期限很糟糕 > [just like 1 to 1 is bad…]为什么？

                  我已经回答过了 因为政治原因，一个这么小的项目，如果团队里只有一个刚毕业的学生，就会夭折。而且也会无聊透顶。所以，如果我离开了，我相信那个新毕业的学生也会离开。这就意味着雇佣我们俩的公司必须再雇佣两个新人。这已经是很多年前的事了，但我想有些当初的应届毕业生应该还在。部分原因是，那个团队的工作其实很有趣。他们都是好人，和他们在一起很开心。只有两个人的团队很无聊…… 我知道，因为我也曾在那个团队里做过所有的工作，那是一种心灵上的折磨，也是我离开的原因之一。

                  回复

                  1. >>但那个团队是 5 比 0。

                    >你所说的病态团队？是的，很糟糕。错过最后期限是很糟糕的。>>[就像 1 比 1 是不好的……] 为什么？

                    >我已经回答过了。因为政治，一个项目

                    我感到困惑，因为我以为你想说的是一般性的观点，但显然你陷入了一家公司及其极其具体的项目和政治的细枝末节之中。

                    我得到的印象是，这个项目受到了太多特殊的限制，根本不可能有其他的发展，因此，我们没有办法批判性地评估如果有不同的安排，事情是否会发展得更好。尽管如此，我不知道我们应该从这样一个受限的例子中得出什么样的一般性结论？回到链接的文章，蒂姆的案例似乎并不那么受限：

                    1）他们曾想过除掉蒂姆，这大概不会使项目完全夭折。

                    2）他们期望蒂姆做出更多个人贡献，这大概也不会完全扼杀项目。

                    3）团队中已经有了初级和高级工程师的组合，而不仅仅是蒂姆和一群新毕业的学生。

                    回复

    2. >蒂姆是作为教师或培训师被聘用的吗？

      你认为这有什么关系吗？一般来说，软件开发工程师都是作为小团队的一员受雇参与项目，他们的目标是交付项目。这与故事点无关，与烧毁图无关，与公关无关，与触及的 LoC 无关。他们的目标是交付多少项目，让每件事、每个人都不出问题。这意味着，如果你陷入困境，你的团队也会陷入困境，直到你解除自己的障碍。如果你能让一名团队成员坐在你身边，帮助你解决问题，那么这名团队成员就是在帮助团队。

      回复

      1. >如果你能通过让团队成员坐在你旁边，带着问题去解决，从而解除自己的障碍，那么这个团队成员就会帮助团队。

        我对这一点没有异议，因此有 20-30% 的配对。但是，如果团队中每天都有至少一个人被阻挡，那么你不需要 “蒂姆”，你真正需要的是一个新的团队，因为这种阻挡程度是不可接受的。

        回复

        1. >因为这是一种不可接受的阻塞程度。

          你真像个经理。等你找出并迅速解决团队经常受阻的所有原因后，再告诉我。在那之前，我们还有蒂姆。

          回复

          1. >你听起来像个经理。

            是啊，我觉得读得不错。

            给管理层点赞，他们很聪明。他们大多只提拔我们中最狂热的泰勒主义者。

            回复

            1. >为管理层的聪明才智点赞。

              恕我直言，这与聪明恰恰相反。请注意这样一个事实：从各方面来看，蒂姆的角色实际上是团队力量的倍增器和产出的助推器。还要注意的是，你认为蒂姆应该被解雇，整个团队也应该被解雇，仅仅因为… 你的 Jira 指标有偏差？到目前为止，这还称不上聪明。

              回复

              1. 你假定管理层对你所分享的需求进行了糟糕的优化。

                你还认为我说的 “聪明 “没有贬义。

                如果你能听到我说这些话，而不是读到我打出来的文字，至少后一点是无需澄清的。不幸的是，这样的文字是没有味道的盐。

                回复

            2. “泰勒派 ”是一个众所周知的说法，还是你在模仿泰勒系列的概念？哈哈。

              回复

              1. 泰勒是一位著名的管理研究者，他创立了一个全新的管理学派，该学派甚至在泰勒去世前就已发展成为与泰勒本人所持理论完全不同的学派。

                关于兄弟姐妹的评论，我只想指出一点，泰勒主义并不是一个贬义词，它是一个管理学派的正确名称。对这个名称的任何贬义暗示都是其思想质量的结果，完全是实至名归。

                回复

              2. 它指的是 “科学管理”，又名泰勒主义（Taylorism），这是一个贬义词，上一次劳工在这个国家拥有类似于我们应得的权力时，这种现在已普遍存在的做法被正确地称为 “科学管理”。

                回复

        2. >但是，如果团队中每天都至少有一个人受阻，那么你不需要 “蒂姆”，你真正需要的是一个新的团队，因为这种受阻程度是不可接受的。

          我不认为你的意见是有根据的，也不认为你的意见是基于在一个正常运转的团队中工作的经验，更不用说是一个高运转的团队了。任何团队在处理非琐碎的项目时，都会遇到难以捕捉的关键错误，或者如果有一个主题专家坐下来向某个人传授经验，就能更快地推出新功能。如果你关心性能和上市时间，这已经是你的基准线了。如果有一打牛仔式的开发人员，即使团队成员着火了，他们也不会向其撒尿，这样的开发人员并不会给你带来更好的效益。

          回复

          1. >我不认为你的意见是有根据的，也不认为你的意见是基于在一个正常运作的团队中工作的经验，更不用说是一个高运作率的团队了。

            你对我的假设太不可思议了。>任何团队在处理非同小可的项目时，都会偶然发现难以捕捉的关键错误，或者如果有一个主题专家坐下来向某个人传授经验，就能更快地推出新功能。

            你又在争论我从未反对过的观点了。事实上，我明确主张花费一定比例的时间进行配对。

            回复

        3. 这取决于他们在做什么，以及团队的资历有多浅。对于涉及面相对较广的工作，如果团队里有几个刚毕业的学生或对问题领域缺乏经验的人，这并不奇怪。这种情况在快速发展的公司尤为常见，因为这些公司的团队通常都是新人居多。

          现在，理想的情况是不要依靠一个 Tim 来完成这项工作，那是一种失败的模式（我偶尔也做过临时的 Tim，但目标始终是让团队更加自给自足，避免成为永久的 Tim）。兼职提姆始终把自己的部分时间花在疏通他人上，这在我看来是一种相当普遍的现象，而且很可能是必要的。

          回复

        4. 雇用 5 名后辈并让蒂姆精神崩溃比雇用 5 名蒂姆更省钱。

          但现实情况是，如果你真的雇佣了 5 个 Tims，那么你只需用 1/5 的时间就能完成工作，而且软件在第一次迭代时就会很不错。

          在我看来，咨询公司实际上想要的是没有经验的开发人员，因为在培训他们成为有用人才的过程中，他们可以向客户收取没有经验的费用。这太可怕了，而且如前所述，这也是那些不得不忍受他们胡扯的 Tims 精神崩溃的主要原因。而对于后辈们来说，也是如此，他们总是在火线之间奔波，试图解决他们造成的混乱局面。

          这不是你应该做的事情，但每个人都是这么做的。在某些时候，这只是盲人带瞎子，因为蒂姆还有其他事情要做，不可能一个人审查每份公关报告上的每个 LOC。

          顺便说一句，我并不是靠别人的指导才成为资深员工的。我之所以成为资深人士，是因为我一直热爱我的工作，仅此而已。网络和实体书对我的指导是非个人的。所以我相信他们也能很好地指导其他人，我不明白为什么我应该浪费自己的时间，就因为我的老板很吝啬，只能雇用几个有我这样的经验或工作之外的学习动力的人。

          让我们把话说清楚–指导和受教是两码事。我对后者并不苛求。我吝啬是因为我想写代码，我不想告诉别人他们应该学会他妈的阅读错误信息，并且每隔 5 秒就谷歌一次。

          虽然现在我是非常残酷的诚实。实际上，我在人前对他们很友好，也很有耐心。但这让我时不时就会崩溃，因为我暗地里很讨厌这样！

          回复

        5. 为什么不能接受？加入一个全新的团队所造成的时间/生产力损失难道不会完全超过 100%配对 Tim 所造成的时间/生产力损失吗？

          回复

      2. 是的，很明显，你对软件工程师的工作有根本性的误解。我们不是 “构建系统”，而是为管理者分散风险。如果有人在 “帮助构建某些东西”，他们可以花自己的钱来做这件事。这就是生意，做得越少，赚得越多。

        回复

    3. 在很多公司，高级工程师的定义是帮助他人发展技术技能。

      回复

      1. 在其中一些公司，工作也是如此。

        回复

        1. 我认为这种说法过于愤世嫉俗。它应该始终是工作的一部分（除非在某些地方，头衔膨胀到了一定程度，头衔其实根本没有任何意义），而且通常也是如此。

          回复

    4. 非常有趣的话题，正如你所说，比例在很大程度上取决于他在团队中的指定角色。

      对于技术主管来说，我认为比例应主要偏向于帮助其他团队成员（通过配对或跨领域工作，通常是开发设计/信息安全）。比如 20/80，其中 20% 的个人贡献是最难的坚果，其他人无法在合理的时间内完成。

      对于高级开发人员，我认为这取决于团队的组成。如果有一位资深开发人员和三位初级开发人员，那么培训他们应该是他的首要任务。如果有 5 名专业性很强的资深开发人员，我认为比例应该倾向于个人贡献。

      回复

  6. 反例： 并非所有事情都需要集体活动或社交。如果一个技术一般的开发人员在没有 “Tim “不断帮助的情况下都无法完成一项功能，那就说明你的代码、流程和团队有问题。我曾在一些地方工作过，他们把配对作为团队合作良好的信号，而实际情况是代码非常脆弱，充满了黑客，需要 Tim 的帮助（通常是精神上的支持）来支持每一个小改动。

    每个团队都不尽相同，但软件开发需要个人工作的时间和空间，就像小组工作一样。如果一个小团队需要一个专人负责配对工作，而这个专人又不做（或不愿意做）任何集成电路工作，那就是一个巨大的红旗。

    回复

    1. 不要忘记软件的类型。一些非常专业或重算法的软件（重科学或数学）可能比 CRUD 应用程序更难单独完成。

      回复

      1. 我的经验正好相反。简单的东西比较容易配对。真正难的东西则需要单独完成。例如，我认为博士生的工作大多是一个人完成的。

        并不是说不可能通过合作完成艰巨的工作，但我认为很多繁重的思考都是一个人完成的（如爱因斯坦、牛顿），很难让其他人保持同步。

        回复

  7. 是啊，我参加过的最好的团队中，总是有蒂姆这样的人。

    在我参加过的最好的团队中，蒂姆的乐于助人精神会渗透到其他人身上，而不是蒂姆总是一个人，过程是这样的：

    1. 开发人员被困在

    2. 开发人员根据问题和资源情况（例如，有些东西更容易在内部搜索，或者拆开来一块一块地找），在适当的时间内尝试自我解卡

    3. 开发人员宣布 “嘿，我在 XYZ 事情上被卡住了”

    4. 最了解该主题的人（不一定是蒂姆，但通常是蒂姆）会将其列为最优先事项，并且几乎总是会立即跳出来提供帮助（除非他们无视聊天，因为他们已经进入状态）

    如果在休息时间（比如午餐时间或站立时间）进行第 4 项工作，效果会更好、 每个人都有足够多的事情要做，他们可以做自己内部的 CPU 流水线并做其他事情，直到有人有时间帮他们解压

    回复

    1. 根据我的经验，很多团队的问题是人们跳过了 #2。

      好的开发人员总是做第 2 项工作，坏的开发人员则跳过它。

      回复

      1. 这很容易解决。当他们问我的时候，我可能需要一两个小时才能回复他们。如果他们只是想把我当成橡皮鸭，那问题早就解决了。不仅仅是开发人员。PM 也有这种行为。在询问他们需要什么之前先坐下来，大多数问题都会消失。

        回复

      2. 为那些在第四步坐下来并列出他们已经尝试过的所有方法的人加分，这样问题的来龙去脉就一目了然了

        回复

  8. 当你看到每秒伤害图表并得出结论说你的所有治疗者都需要被踢出突袭时。

    很难量化 “辅助 ”的价值，但他们是不可或缺的。我还没有真正找到量化它的合理方法。归根结底，你需要相信领导者能做好这件事。

    回复

  9. 标题应该是： 为什么用故事点来衡量开发人员的生产力是糟糕的？

    我曾经所在的团队也有一个零故事点的开发人员，我们就叫他 “零 ”吧。他总是拒绝在计划中分配任何故事，他的目标永远是零。他觉得自己有责任完成所有计划中的故事，并帮助那些有困难的人。他经常来找我，让我帮助某个人完成特定的任务，因为要帮助所有人对他来说太难了。

    不过，管理层对此非常理解。零点每年都会放 4-6 周的假，如果零点不在，管理层总是会把重要的发布推后。没有他，团队也能完成任务，而且在所有重要的版本发布时没有 Zero 在身边，对团队来说可能会更好。但管理层害怕没有他，会出什么大问题。

    回复

    1. 那么，“零 ”不就是变相的英雄吗？

      当我听到关于蒂姆或零的故事时，我觉得很有道理……但要注意的是，他们是否真的在向队友传授知识，以及其他团队成员是否有能力接管蒂姆/零的职能。如果没有，那么 “零 ”就只是在为表现不佳的人打掩护，而你的总线因素仍然是一个负担。

      回复

  10. 有些事情并不能衡量开发人员是否 “优秀”：

    – 添加、更改、删除的 LoC #

    – 在冲刺阶段获得的分数，而这些分数并不能量化地反映业务价值、 – 为巩固与业务部门的关系和 “玩游戏 ”而与他人周旋的昼夜时间

    – 在会议或演示中 “听起来像优秀开发人员/聪明人 ”的次数

    – 他们花了多少周时间来解决真正复杂的问题，而他们本可以更早、更快地提供更多增量价值

    – 他们快速为公司提供了多少解决方案，却留下了多几倍的 LoC 需要维护

    – 他们花了多少小时来打磨代码、 他们花了多少时间打磨代码、格式化、更新到最新版本，但这样做只是为了满足自己的喜好，而不是专注于团队和业务，以及什么能帮助他们

    等等。..

    回复

  11. 很难相信，这个人的代码如此错综复杂，让我头疼不已。我见过很多，但这个最牛。

    回复

  12. 所以，真正的衡量标准是了解自己团队和每个成员带来了什么的经理。

    回复

    1. 是的，绝对是这样–而且能够有效地将这一点传达给他们的经理。

      回复

  13. 听起来蒂姆是经理。这位受薪经理到底在做什么？

    回复

    1. 经理有不同的类型。我会用技术负责人来称呼蒂姆。需要有人管理产品交付。需要有人管理积压工作。需要有人管理每个人的培训。需要有人确保员工为下一份工作做好准备。需要有人确保每个人都能得到合理的报酬。当两个人合不来时，需要有人来处理。以上只是全部清单中的一小部分，我并不了解全部清单中的所有内容。

      回复

      1. 我并不想成为一个彻头彻尾的混蛋……但是：

        >需要有人管理产品交付：

        你是说将 2 周的交付周期转变为自动化的 CI/CD？好家伙，我希望他们没有一个没用的Scrum Master。

        >需要有人管理积压工作：

        >需要有人管理每个人的培训：

        >需要有人确保员工为下一份工作做好准备：

        >有人需要确保每个人都能得到合理的报酬：

        ，据我所知，人力资源部门只有一项该死的工作。

        >当两个人合不来时，需要有人来处理：

        嘿，蒂姆，你能指认那个混蛋吗？你在招聘/解雇方面有多得心应手？

        显然，在我看来，非技术管理人员除了玩弄政治，阻止解雇那些被错误雇用的笨蛋之外，什么也没做。

        回复

        1. 你有担任技术主管和/或经理的经验吗？在许多组织中，技术主管和人事经理是两种截然不同的角色，这是有充分理由的，包括但不限于他们都是全职工作。这当然取决于公司、团队规模和其他因素，但很多技术主管根本不擅长招聘和解雇，也不擅长面试、安排工作优先级、产品管理、与管理层会面、批准请假申请、处理投诉、决定加薪和晋升、处理设备和管理预算……你对这些角色的轻描淡写，让我不得不认为你可能并不了解其中的真正含义。

          回复

          1. 要区分能不能雇用和解雇，还真是花了不少心思。我想知道蒂姆会怎么做。

            回复

            1. 所以你就认为，博文中没有描述的虚构人物对你一无所知的组织没有贡献？你的观点是所有的管理都是无用的吗？还是别的什么？你为什么这么肯定，你有什么管理团队或公司的经验？也许你的讽刺没有有效传达你的观点？

              回复

        2. >据我所知，人力资源部门只有一项该死的工作。

          没错。保护公司。只要任何人的工资单上没有真正写上诽谤的字样，人力资源部对此事的兴趣大致就到此为止了。

          不要觉得自己被骂得太厉害。如果我认为你在其他方面说错了，我会说出来的。

          回复

    2. 相反，他每天都会与不同的队友配对。对于经验较少的开发人员，他会耐心地让他们开动脑筋，同时引导他们找到解决方案。

      这不是管理活动–这是高级 IC（”个人贡献者”–我仍然很讨厌这个词）应该做的辅导工作。

      一般来说，我认为 “经理 “应该对公司里的其他人有管理权：进行绩效考核、处理晋升、聘用和解雇。

      我认为，重要的是公司要提供一种职业结构，让员工能够发挥影响力、做出决策和担任领导职务，而不需要同时承担这些管理任务。管理任务非常耗时，所需的技能也与故事中蒂姆那样的优秀团队教练或倍增器大相径庭。

      回复

      1. 虽然我不太清楚故事中的经理应该做什么。他们的附加值在哪里？如果只是在 MBA 上玩心理游戏，那么我认为他们可以去死了。

        回复

        1. 这可能是一家大公司。可能会有几层 C-levels，一层经理听他们的，把他们的命令变成具体的事情，然后是几层管理层，以确保来自顶层的混凝土砖块在击中时不会损害实际生产力。

          回复

      2. 我同意这一点，但管理者也许应该有足够的接触，让他们自己看到团队行为。

        回复

        1. 他们确实这么做了……这就是文章的整个前提

          回复

          1. 我不确定这个故事是否真实，但很明显，在他的经理不知情的情况下，这种情况持续了足够长的时间，经理死心塌地地为 Tims 的离职做准备

            回复

          2. 很多人似乎都把注意力集中在了 “经理的决定 “上，却完全忽略了这是指部门经理，而不是团队经理，故事也是从团队经理的角度讲述的。

            回复

    3. 显然，他还在执行另一项不被重视的任务：充当蒂姆的缓冲器，让团队即使在不遵守公司政策的情况下也能蓬勃发展。以及教练之外的所有其他管理工作。

      回复

  14. 今天上午，我对与蒂姆的角色有些相关的编程实践和语言设计进行了一些思考。

    我经常写代码给别人看，明确地教他们如何做某事。这些代码总是过于冗长、”解压”，教给人们的是一个解决方案背后的思维过程，而不是一个 “整洁 “的解决方案。我是在有点不情愿的情况下被拖入这种风格的，因为我不得不提前预测代码可能被误解的所有方式–之前被误解的所有方式。对我来说，事先啰嗦比事后纠正误解要省事得多。

    在观摩了一些最优秀的系统编程代码/编码员之后，我认为这才是编程的最佳方式。

    我用这种方法编写的最新程序，代码质量大大提高。没有缩写，任何不寻常的编码实践（例如，有条件导入、使用类作为命名空间而不是对象模板等）我都会在注释中简要注明，以突出它的意外性。任何针对特定领域/应用程序的函数都有很长的名称，以充分描述该步骤/部分的解决方案。广泛的设计注释中注明了我的想法，等等。

    程序教读者如何思考解决方案，而不是如何理解代码–教给 “聪明的初学者 ”而不是专家。我认为这不同于有文化的编程，也不同于 “代码是读出来的，而不是写出来的 ”这句格言，它是一种特殊的 “教育伦理”：代码不是简洁的、有文化的或可读的，而是有教育意义的。

    如果这是 “大型编程 “的最佳方式，那么编程语言的一个特性就是：能够让程序员在多行代码中 “解压 “其思想的语言比阻碍这种解压的语言更受欢迎。我想这就解释了为什么函数式语言会被广泛接受–因为函数式语言抵制在代码行上进行思想解压。功能语言通常以其简洁性为卖点，就好像一个 200 行的 C++ 程序应该缩减为一个 10 行的 F# 程序。但这是一种错误的生产效率：长期存在的大型程序要求程序员建立心智模型的次数，远远多于他们在程序中添加内容的次数。程序员自学代码库的次数要多于编写代码库的次数：这与阅读无关。

    这在某种程度上与 OP 中 Tim 的角色有关。也许正确的软件工程编程实践应该是：在编写代码时，就像未来要与新程序员配对一样。把蒂姆想说的话都写在代码里。

    回复

  15. 诚实的问题： 是否有任何关于开发人员工作效率的指标能够真正发挥作用？多年来，通过阅读这样的故事和其他故事，我得出了这样的结论：你根本无法从细微的层面衡量开发人员的工作效率，它只与最终产品有关。不过，我很希望事实证明我是错的。

    回复

    1. 我认为，即使所有员工都担任相同的角色，现实中也没有任何好的 “个人 “生产力衡量标准可以适用于广泛的员工。我参与过的每个团队，即使在成为开发人员之前，都是由以不同方式为整个项目做出贡献的人组成的。试想一下，如果用每天插入的螺丝数量或每天焊接的数量来衡量汽车装配线上的所有工人，他们的工作效率会有多高呢？按照这个标准，任何在生产线上的主要工作不是拧螺丝或点焊的人都是低绩效人员，但仅靠拧螺丝和点焊是无法组装出一辆完整的汽车的。我认为在软件开发等领域情况更糟，因为团队成员的具体贡献方式可能更加模糊。你很少会因为一个人的代码审核能力或设计能力而雇用他。团队成员总是能以某种方式回忆起系统中最微小的细节，而这些细节是其他人无法从 5 年前的功能工作中回忆起来的，这并不是简历上可以找到的技能，即使你为所有员工量身定制了衡量标准，也无法为其建立一个很好的衡量标准。

      这是一个很难解决的问题。我并不羡慕那些试图找出谁（如果有的话）是团队拖累的员工的管理层。有时情况很明显，存在具体问题，但有时只是 “大家都知道 “某个人是拖后腿的，但如果没有硬性指标，就只能让员工互相排名之类的糟糕事情发生。

      回复

  16. >你看，蒂姆的工作效率得分之所以为零，是因为他从未参加过任何项目。相反，他每天都在和不同的队友配对。

    我很高兴这篇文章采取了这样的立场，因为当我读到前几段时，我正准备在网上写一篇刻薄的评论，说用故事点数来衡量开发人员的工作效率是多么愚蠢。

    我的一个朋友就像他提到的蒂姆一样：他花时间帮助其他人解决问题，或者花额外的时间用正确的方法做事。他的个人速度受到了影响，但团队和代码库却得到了极大的改善。在一家公司，他被列入了绩效改进计划，而在另一家公司，他被告知自己的工作将因此受到威胁。毫无疑问，这让他在职业生涯的这个阶段本应更上一层楼的时候，却只能担任高级职位。我对这件事有点耿耿于怀，因为我曾在给他制定 PIP 的公司与他共事，结果我和他都辞职了。

    当我看到一些公司试图衡量开发人员的工作效率（并将其与就业和晋升挂钩）时，我想到了詹姆斯-斯科特（James Scott）所著的《像看国家一样看问题》（Seeing Like a State）一书，以及可读性的概念：在一个复杂、混乱的系统上强行施加一套规则，使其更容易从远处的某个办公室进行指导。这给管理者带来了极大的便利，却往往导致灾难。

    回复

  18. 在我的公司里，我会告诉他开始做一些工作，把故事写出来，否则他就走人。是的，他在协助他人方面很有用，但我很容易就能找到同时能做这些工作和自己工作的人。他不需要一直坐在那里和其他人在一起。现在的情况很可能是，蒂姆在扮演他的老板，渲染他的配对角色及其好处，以便无所事事地看着别人工作，同时提供评论。

    回复

  19. 我从来没有想过，反驳 “不使用代码行数或解决的错误，因为它可以被玩弄”，只是为了指出生产率实际上总是被玩弄

    回复

    1. 他们甚至有一个华丽的标题，”测量功能障碍”，和一个自以为是的 “如果你知道你就知道 “的绰号，古德哈特定律

      回复

      1. 和坎贝尔定律，以及 CObra 效应。

        我以前从未见过 “测量功能障碍”。这个短语很有用。

        回复

        1. 与此相关的一种现象是麦克纳马拉谬误

          回复

  20. 这类故事在 HN 和软件工程社区似乎是家常便饭，而且被怪异地传颂着。

    我们听说过这样的英雄，他与经理和高管对着干，没有按照约定在冲刺阶段交付任何故事。

    我们听说有工程师因为不会反转二叉树而不被谷歌录用。其他人也纷纷表示，的确，你不能用 Leetcode 或白板问题来衡量开发人员的效率。我们太优秀了。另一位工程师插话道 “我不测试我的候选人。与我共事过的最优秀的人都是在当地酒吧喝啤酒聊天时被录用的。”

    有人告诉我们，MBA 引入了邪恶的衡量标准，破坏了组织，我们所做的工作是无法衡量的，PHB 不了解我们有多优秀。10倍工程师并不存在，在我们的数字乌托邦里，每个人的生产力都是一样的。

    与此同时，在现实世界中，成群结队的糟糕工程师不会带来任何故事点，因为他们实际上什么也没做，只会浪费时间和降低士气。

    与此同时，在现实世界中，每个工作机会都有成千上万个几乎不会写 for 循环的求职者。Leetcode 和白板每天都能有效地过滤掉这些人。

    与此同时，在现实世界中，对交付、功能和错误的衡量标准推动着公司的发展，也是那些雇佣他们的公司取得成功的原因。

    在我看来，所有这些英雄，以及高于流程的人，只是让我觉得很难与不善于沟通的自恋者共事。我们并不特殊，也不会凌驾于公司其他部门之上。

    回复

    1. 同意第一和第二个 “同时”。关于度量标准，我的经验恰恰相反–充其量只是轻微的分心，最糟糕的是完全是灾难和生产力杀手。大多数组织甚至无法全面（或根本无法）实施度量标准，因为在现实中，度量标准的工作量总是比他们通常预计的要大得多。反之，他们就像谷歌一样玩游戏，浪费你那该死的时间。

      说到这里，我确实认为，有一群自以为是蒂姆的高层人士，但同时他们只是通过卷入别人的烂摊子来掩盖自己的懒惰/无能

      回复

    2. >我们被告知，有一位英雄，他与经理和高管对着干，却没有提供任何故事

      &gt； 与此同时，在现实世界中，成群结队的糟糕工程师没有交付任何故事点

      你认为这里的重点是，没有交付一个特定指标是件好事，还是不能把没有交付一个特定指标视为全局？

      回复

      1. 是后者，但我想说的是，这样的论证既老套又无力。

        博客发帖人本可以问，为什么经理希望我提供故事点？因为杰克的故事点也是零，而且他是个糟糕的工程师，这是一个很好的金丝雀指标。

        回复

    3. 具有革命（或 “创新”）气质的人都会说：”这个系统行不通，这些流程坏了，出现了错误的结果”，但他们却置之不理。在这样做的过程中，他们只是根据自己的判断 “做正确的事”，并在这样做的过程中开发出下一个迭代流程，让其他人效仿。

      如果这些创新者所处的利基市场需要创新，那么他们所解决的问题就与其他大多数人不同，他们就会有不同的自我定义标准（”自恋”），等等。

      可能许多访问 HN 的人都有这种气质，而且相当多的人所处的利基市场需要这样发展（例如，这适用于所有初创企业）。HN 只是工程师的一个小样本：大多数人不会去网站构思自己的活动、进行反思等。这些都表明，人们渴望创新，或解决其专业领域的新问题。

      如果你处在一个高度稳定的环境中，拥有有效的流程等，那么这种性格的人如果完全任其发展，可能会带来麻烦：好的管理者会把他们安排在一些需要弄清楚的未知数的项目/领域中。

      然而，在很多情况下，没有这种性格的人（比如说 “它是有效的，不要破坏它，保守派”）会觉得这种行为令人不安、傲慢、具有破坏性和孤立性–因为它就是这样。当你还没有想出解决办法时，就没有任何东西可以 “交流 “了–你可以每天公布你的思考过程，但当更多的人看到你的思考过程（根据更多的思考、信息等）发生了多大的变化时，这只会让更多的人感到不安。发生这种变化的价值观不是保守的，而是激进的，是一个看到了摆脱困境的途径的人强加于人的。把自己置于这种境地，或者认为这是自己的无形责任，而别人不具备这种责任，都是非常傲慢的。

      无论如何，如果你在这个利基市场中运作，尤其是在创业环境中，那么你根本不会关心这个 “真实世界”。他们的行为与现实世界背道而驰，是为了改善现实世界。

      回复

      1. 谢谢你的回复。我明白你的观点，但我认为你的观点与我的观点略有不同。

        如果我可以抓住你的第一段不放的话，我的观点是，我们说的第一句话是 “这个系统坏了”，并乐于在证据不足和以偏概全的情况下，把孩子和洗澡水一起扔掉，把一切都撕碎。

        是的，关于 HN 群体具有创新气质的说法肯定是有道理的，但我不认为这与我的观点有任何正交之处。事实上，我们这个群体比其他大多数人都要理性得多，所以我也希望我们能理性地看待公司的流程，但不知为何，当涉及到我们的经理和高管以及他们每天让我们经历的 “恐怖和麻烦 ”时，我们似乎总是视而不见。

        回复

    4. >>在我看来，所有这些英雄，以及流程之上的人，只是让我觉得很难与不善于沟通的自恋者共事。我们并不特殊，也不凌驾于组织中的其他部门之上。

      没错。

      在我看来，蒂姆非常善于在别人背后隐藏自己的无能。另外，当蒂姆不请自来地坐在他们旁边一起 “配对程序 “时，其他人，尤其是高级人员没有告诉他 “滚开，蒂姆”，这看起来也是一个问题。

      回复

    6. 所以，一方面，你说得有点对。HN 充斥着人们的夸大其词（在我看来往往是有道理的），因为他们不得不整天面对这个系统的糟糕之处。在一个充满开发人员的空间里，这似乎很自然。

      但我不认为你的评论是公平的。

      >我们听说有工程师因为不会反转二叉树而不被谷歌录用。其他人也纷纷表示，是的，确实不能用 Leetcode 或白板问题来衡量开发人员的效率。

      因为这不是评判工程师的好方法。或者说，如果他们不知道如何反转二叉树，这就是一种很好的方法。大部分工作都是要找出一些你还不知道的东西并去做。随机给工程师一个关于晦涩算法的维基百科页面，然后让他们去实现它，是一种很好的面试策略。>同时，在现实世界中，成群结队的糟糕工程师并没有带来任何故事点，因为他们实际上什么也没做，只会浪费时间和降低士气。

      我同意你的观点。这些人应该被解雇。这并不意味着故事点是一个好的衡量标准，通常 90% 的长期价值都来自于像蒂姆这样的人，失去他们会毁掉项目。不能因为发生了不好的事情，就把团队 90% 的价值扼杀在摇篮里。

      我所见过的唯一有效的方法是，给予团队经理更多的自由裁量权，并严格解雇那些经常创建表现不佳团队的经理（为此，你往往不得不提高经理的薪资，这没什么，好的经理是物有所值的）。

      >与此同时，在现实世界中，每个工作机会都有成千上万个几乎不会写 for 循环的求职者。Leetcode 和白板每天都能有效地过滤掉这些人。

      你确实需要筛选会写代码的人。但这并不意味着筛选二叉树倒置的人是个好主意。>同时，在现实世界中，交付、功能和错误等指标推动着公司的发展，并使那些采用这些指标的公司获得成功。

      胡说八道。基本上所有公司都使用衡量标准，而大多数公司在交付有用软件方面都是垃圾。一家公司在一个软件项目上落后数年，超出预算一百万美元，最终交付出人们不想要的东西，这已经是老生常谈了，以至于人们已经预料到了。而这些公司经常被小团队用 1%的资源打败，只要这些小团队有半点用心。事实上，如果你想让我来衡量团队的成功与否，那么团队中有多少人真正关心这件事就是一个很好的标准。

      你提出的解决方案只有 20% 的成功率。别搞得好像这是一个能将业务价值推向新高度的黄金标准。就目前的系统而言，大多数公司最好退出软件行业，让第三方代劳。

      回复

      1. 我更广泛的观点并不是说公司的运营方式是完美的，我们应该阻止 “创新者”（引用兄弟姐妹的评论）。每一个例子都说明了企业的功能失调，但我们却从未重视迫使它们存在的制约因素。Leetcode 是很糟糕，但它的糟糕之处在于它过于偏重于过滤假阴性–这是两种错误中较为低级的一种。另一种选择更糟。

        在这个故事中，我们姑且相信蒂姆，但事实仍然是，每一个像蒂姆这样非凡的隐形巨星，就有 99 个表现不佳的人与他无异。

        我们需要对我们的管理者和组织流程感同身受，以了解他们的目的以及他们是如何形成的。

        我们，软件工程师，总是挑出一些单一的证据数据来指出这个世界的缺陷和不公平，这与我们自我膨胀的想法背道而驰。

        酿酒师倒置二叉树和蒂姆的伟大，并不能否定白板和故事点的普遍做法。

        关于你的最后一点，我工作过的最好的组织都非常有效地使用了度量方法（大多是在初创企业）。最差的组织也是如此。有些人做得不好，并不意味着所有的人都做得不好。

        令人厌烦的是，在软件开发中，反传统的理念在被这个社区当作福音之前，对其所要求的证据质量的不公平和低期望值。

        而且，根据我的经验，那些最强烈支持回避或废除这些流程的人，与那些同样没有为团队带来价值的人有很大的重叠。

        回复

        1. >Leetcode是不好，但它不好的地方在于，它过于偏重于过滤假阴性

          但事实并非如此。它过滤的是与开发无关的东西，即沉迷于巧妙算法解决方案的能力。好吧，我的公司采用的是 HackerRank 而不是 LeetCode，也许 LeetCode 会神奇地更好，但我并没有看到任何东西能告诉我，磨练 LeetCode 的人在我的团队中会真正有用。

          听着，你想要一个白痴检查来确保某人真的会编程，很好。这也许是个好主意。>在这个故事中，我们姑且相信蒂姆，但每一个像蒂姆这样出类拔萃的隐形巨星，就会有 99 个表现不佳、与他无异的人。

          但他们并非没有区别。博文作者完全能够将他们区分开来。这就是我的观点。有很多方法可以区分他们，只是这个指标不是其中之一。因为这是一个糟糕的指标。

          >我们需要对我们的管理者和组织流程感同身受，以理解他们的目的以及他们是如何产生的。我确实对管理者和组织流程感同身受，以理解他们的目的以及他们是如何产生的。

          我确实对管理人员有同理心，至少是低层管理人员。这就是为什么我主张让他们完全掌控组织，给予他们单方面解雇的特权，并提高他们的薪酬。

          >我所工作过的最好的组织都非常有效地使用了衡量标准（主要是在新成立的公司）。最差的也是如此。

          你说得好像衡量标准（至少在软件领域的传统做法）与成为一个优秀的组织是对立的。如果真是这样，我们也许应该重新思考一下，我们在这些指标上花了多少时间，又花了多少钱。

          现在，如果你想用利润、采用率或用户满意度作为衡量标准，我很乐意与你讨论这个问题，但我在企业界的经验告诉我，我们目前使用这些标准的方式甚至没有任何净正面价值。

          回复

  21. 故事的寓意：

    任何寻找最薄弱环节的人，其内心都是最薄弱的。

    回复

  22. 真遗憾，故事中的迪尔伯特链接断了，失去了太多的历史。

    回复

  23. 蒂姆斯的工作似乎很适合我。

    我喜欢闲逛，告诉别人哪些地方可以做得更好。这通常会导致我看起来不讨人喜欢，因为我经常指出错误。

    回复

    1. >这通常会导致我看起来不讨人喜欢，因为我经常指出错误。

      孩子们常说的 “沟通障碍”。沟通是一种技能，我们有可能在这方面做得更好，并以一种让人们喜欢你的方式帮助他们。

      回复

  24. 那么，有没有一种方法可以捕捉到蒂姆帮助处理这么多 JIRA 故事的事实，从而使蒂姆的工作更加显而易见？比如说蒂姆拥有的结对编程故事，并在板上移动（假设蒂姆的时间最好用在指导上）？

    这有点让我不舒服，因为 Tim 可以在雷达下随心所欲地工作，而不需要任何书面记录或责任，而团队的其他成员则必须清楚地表达他们在做什么

    回复

    1. 你可以把子任务放在故事下面，Tim 可以有自己的子任务来代表他的贡献。如果领导层/管理层想变得非常迂腐，还可以（通过扩展）将时间与子任务相对应。每个团队成员在每个冲刺阶段至少要有一个指定的故事/任务/bug，而 Tim 在冲刺阶段至少要有 x 小时记录在故事之外的子任务上。

      或者，你也可以相信你的团队，让他们在一个时间窗口内完成他们说可以完成的故事。让他们在团队层面想办法。

      回复

  25. 嗯。在敏捷的世界里，非编码人员通常不会参与故事的编写。所以，也许我们不应该指望这个人编写故事，或者预算中没有足够的空间让他只做一个同行编码员。我个人喜欢把故事范例作为确定（并坚持）优先事项的一种方式，我喜欢经理和负责人像其他人一样为故事工作。此外，在远程工作环境中，每个人都必须更加努力地找出正确的工作方向，而故事正是实现这一点的好方法。

    回复

  26. 我喜欢好的配对阶梯。虽然没有衡量工作效率的绝对好标准，但一套思想观察至少可以提供绊脚石。

    要求手工艺者进行数据录入以显示其价值的工具存在一个主要问题，那就是最优秀的人最有可能拒绝。你确实需要专注于工具，以帮助捕捉正在发生的事情，而无需劳神费力。

    例如，如果您的员工在远程工作，而且他们使用软件（如 Tuple）来帮助配对，那么您可以编写系统脚本来记录 Tuple 会话，甚至可以捕捉一起提交的配对。

    这可以作为一种输入，使您的组织中出现可见的最佳领导者。

    回复

  27. 我明白他们想表达的意思，但蒂姆应该想办法把东西交付出去。听起来，如果他这么做的话，他可以交付很多东西，让代码库变得更好。

    回复

  28. 这些文章都是可以预料的，而且总是自以为是。

    “报告显示，我的团队中有一个绝对最差的程序员。我解雇他了吗？没有，实际上我给他加薪了 20%。

    你知道为什么吗？他是我团队里最好的程序员（变相）”。

    回复

  29. 也许吧。

    也有些人配对是因为他们是其他一两个工程师的拐杖。其他工程师永远不会进步，或者被辞退，反而拖累了团队。

    还有一些人配对是因为他们的代码本身没有意义。或者他们有一些配置文件拒绝检查到 repo 中，等等。

    配对让他们感觉到自己的价值。

    回复

    1. >还有……配对的人是因为他们是其他一两个工程师的拐杖，[他们]永远不会进步。

      我可以想象，如果这对搭档都不善于沟通，而且最年长的那个人从不时不时地进行苏格拉底式的对话，这种情况就会发生。

      回复

  30. 经理怎么会不知道蒂姆没有预定给他的票呢？蒂姆怎么会连一些票都没拿到（容量较小），然后还在剩余的时间里帮忙？

    我想，作为一个和蒂姆做着同样工作的人，我敢打赌其他人也会有同感，我仍然 “必须 “取票，我想这是我做 IC 工作时的期望。蒂姆的时间管理得好吗？

    回复

  31. 写得不错。

    但我们的人工智能霸主需要他们可以使用的衡量标准。

    回复

  32. 在这个法律硕士盛行的时代，蒂姆会做得很好。他们写代码的速度比任何人都快，但也比任何人都需要更多的指导和辅导。无论我们如何称其为机器学习，他们都学不到任何东西。如今，我们最需要的是 “蒂姆中的蒂姆”（Tim of Tims）–一个指导软件工程师成为蒂姆的人。

    回复

  35. 我从未在一个没有将故事点转化为时间的团队中工作过。我发现故事点是一种完全无用的间接层次。真正的问题是，这里有人觉得故事点有用吗？

    回复

  36. 我认识的最差劲的程序员，一天到晚不是检查代码没有编译成功，就是在开放式的大办公室里说一些令人毛骨悚然的性话，我们都齐心协力把他炒了鱿鱼。

    回复

    1. 第一个问题可以通过 CI/CD 和适当的分支策略来解决。每个集成电路都应该有自己的分支，然后公关到相应的分支

      关于第二个问题，除了人力资源部门的来访，我也不知道。

      回复

      1. 我是负责 CI/CD 的人。我毫不夸张地说，这个人的代码就是无法编译，他们也不会在本地进行测试。

        回复

  37. 一个简单得多的解决方案就是给他分配一个团队改进票据，然后收工。

    不过我怀疑他从来没有参与过任何任务，所以也许可以让他偶尔参与一下。

    回复

  38. 尽管这篇文章为 Tim 说了不少好话，但把他叫出来并把他的 Linkedin 放在标题为这篇文章中实在是太疯狂了

    回复

  39. 这篇文章写得很好，经理们只是想要简短地总结一下正在发生的事情，有时这些总结是以糟糕的指标的形式出现的。

    回复

  40. 以前的黑客新闻：https://news.ycombinator.com/item?id=37361947

    回复

  41. 古德哈特定律不是笑话。价值没有替身。

    回复

  42. 我想这是一年多前在这里发布的。

    我喜欢这个故事。

    回复

    1. 我最喜欢的是它对我团队中更高级工程师的描述。

      回复

  43. 嗯，我想知道保罗-厄尔多斯（Paul Erdos）在数学界是做什么的

    他是数学界的交配蜜蜂吗？

    回复

  44. 我认为这种通过 “故事 “来衡量生产力的愚蠢想法，很大程度上是由于 “敏捷 “行业向 MBA 型经理过度推销他们的低价值 “方法论”，不幸的是，这种经理现在几乎无处不在。因此，一些毫无头绪的人就会根据板子上移动了多少张票来决定谁必须离开。正如乔尔-斯波斯基（Joel Spolsky）曾经说过的，除非有程序员掌舵，否则任何软件公司都不可能成功。

    回复

  45. 还有几件重要的事情需要牢记：

    第一：就像有的人可以带动整个团队，但自己却没有完成任务一样，有的团队成员表面上各自都很有成效，但却因为各种原因拖累了整个团队。根据我的经验，他们通常是：a）速度快但很糟糕；b）编码风格非常怪异，可能并不糟糕，但其他人很难与之共事（架构宇航员和几乎不懂语言的人通常属于这种情况）；或者 c）是流程恶霸，他们试图设置整个审核系统，以强硬的方式执行他们的偏好，这种方式适合他们，但会耽误除他们之外的所有人。每种情况都需要以不同的方式来处理，成功的程度也各不相同，但在现阶段，我的真实看法是，无论这些人自己看起来多么有成效，让他们加入团队多半都是有害的。高层人员的行为问题往往很难调整，而且会耗费管理者大量的精力，而这些精力最好用来帮助你的优秀员工脱颖而出；尽管如此，如果你能让他们调整过来，有时还是值得付出努力的。

    第二：结对编程对某些人很有效，但对另一些人却很糟糕。不幸的是，人们并不能根据自己的喜好来划分，所以 “让他们自己选择 “这种显而易见的方法并不理想。有些人非常喜欢结对编程，并迫切希望一直这样做，但当他们分开时，他们的工作效率几乎是别人的 2 倍（是的，包括下游的 bug 和后续工作，也就是说，他们实际上只是让两个人做了一个人的工作）；也有些人讨厌结对编程，但即使他们讨厌结对编程，也会因为被迫这样做而看到类似的倍数。我的粗略直觉是，这里有两个自变量，一个是衡量你有多喜欢配对的社会因素，另一个是决定你从配对中获益多少的风格因素，两者之间根本没有太大关联。两者之间甚至可能存在轻微的反相关性，因为喜欢配对的社交能力较强的人已经自然而然地进行了尽可能多的知识分享，而讨厌配对的人则对配对投入不足，他们可能需要更多关注自己是团队一员这一事实。

    回复

  46. 我的意思是，我曾在一些公司工作过，管理层会看到蒂姆实际在做的事情，但还是会回答说：”我们付钱不是让他和其他开发人员一起玩的，我们付钱是让他坐在办公桌前写代码的！”

    Vox Jira，Vox Dei。在尝试这样的事情之前，请确保你不是在一家采用这种幼儿园式管理方法的公司工作。

    回复

  47. 我不认为这说明整个系统和前提是错误的，你可以调整一下，让蒂姆在帮助队友时获得一些荣誉。

    在我看来，衡量故事/特色/解决的问题似乎是合理的

    回复

  48. 有点担心作者认为故事点数与商业价值相关….

    回复

  49. 该死。现在读了这篇文章，我才明白为什么我现在的团队感觉什么都做不了，原因就是团队没有蒂姆。

    回复

  50. 这看起来就像是你对你的老板进行了一次社会工程学攻击，目的是把一个客观上表现很差，但碰巧在做一些西方文化中很重视的事情的人留在团队里。

    简而言之，你用一个符合你偏见的临时指标取代了一个定义明确的指标。

    你是个小人物。你只知道你在局部的改进会对整个公司产生负面影响。听你老板的话，如果公司有一个不合适的系统，就让它迅速失败吧。

    回复

    1. 这是一个非常糟糕的回复。文中描述的人基本上是 AWS 的 L6 和 L5 转为 L6。我们的 L6 不编写代码，他们构建 PoC、进行设计、估算并通过他人进行扩展。他们利用自己的经验和知识进行扩展，而 L5 和 L4 则负责工作。

      回复

  51. 我也有过类似的经历。上世纪 90 年代末和本世纪初，我是一家为 Windows 和 Mac 开发实用软件的公司的两名高级开发人员之一。另一位资深开发人员是公司的所有者兼首席执行官，他的大部分时间都必须花在公司所有者/首席执行官的事务上，因此每周只能花一天时间进行开发。

    我们组织大多数 Windows 程序的方式是，我编写一个非图形用户界面核心，实现我们需要的所有底层系统级功能，然后初级开发人员编写一个使用该核心的漂亮的 Windows 图形用户界面。如果产品需要 VxD、文件系统钩子、LSP 或其他 Windows 内核扩展，我也会编写。

    我们当时是盈利的，每季度都会有利润分享奖金（我想……可能是每月一次，但这并不会明显改变下面的内容）。公司老板一直在琢磨如何决定每个人的利润分成。

    有一个方案，他确信一定会很好，就是把一个季度可用于利润分享的总金额除以员工人数。把这个数额称为 “1 份”。因此，如果有 N 名员工，就有 N 份股份。

    他希望将这些股份分配为：25% 的员工分得 2 股，50% 的员工分得 1 股，25% 的员工分得 0 股。谁属于哪一组将由全公司投票决定。

    分发的选票上按字母顺序列出了所有 N 名员工，我们被告知在 N/4 个名字旁边写上 2，在 N/2 个名字旁边写上 1，在剩下的 N/2 个名字旁边写上 0。

    将每个人在所有选票上的数字相加，总数最高的 1/4 人分得 2 份，总数最低的 1/4 人分得 0 份，其他人分得 1 份。

    此外，得票最高的 8 个人将进入一个委员会，就公司的发展方向向所有者提供建议。

    公司所有者在发起这项计划时的期望是，我几乎每次都是得票最多的人，而且总是能进入前 8 名，因此能进入他计划让我参加的 8 人委员会。

    结果我没能进入前 8 名。我甚至没有进入前 25%。我不太记得了，但要么是在 1 股组的下半区，要么是在 0 股组。

    原因很简单。虽然我编写了所有产品的核心功能，但除了其他开发人员外，其他人并不清楚我的角色。编写图形用户界面的是初级开发人员。初级开发人员负责与测试人员进行大部分互动。当测试发现一个错误时，他们会向初级开发人员报告，而对于测试人员来说，初级开发人员就是项目的形象代言人。如果发现了代码中的错误，初级开发人员会通知我。

    因此，每个开发人员都在他们的选票上把我列为第 2 位，但对其他人来说，我只是一个在开发中做着一些不为人知工作的人，所以我没有从其他人那里得到多少选票。

    至少，业主马上意识到了这个利润分享计划的缺陷，并放弃了它。由于他反应如此之快，我也就没有太过幸灾乐祸，因为这正是我在他第一次提出这个计划时告诉他的结果。

    (有些幸灾乐祸是必要的，因为我和老板是 15 年前在大学里认识的好朋友，而当你的好朋友做了蠢事，而你却告诉他们这样做行不通时，你有义务对他们大加指责，这比你不应该对老板说 “我早就告诉过你！”的规则还要强烈）。

    回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注