编写代码是一项脑力密集型工作，就像某人从事一项体力要求很高的工作，之后身体感到疲惫一样，脑力工作也会让人精神疲惫。许多知识工作者表示，几个小时后就会出现“认知疲劳”，此后他们完成任务的能力就会显着下降。
虽然大多数员工每周工作 40 小时，但专家表示，大多数员工无法每天连续进行 8 小时高度专注的工作，因为在达到这一点之前他们会在精神上疲惫不堪。
最近，在 SD Times 的播客 What the Dev? 中，我们采访了 Gradle 首席执行官 Hans Dockter，了解认知疲劳对软件生产力的影响。以下是该对话的删节版：
SD Times 主编 David Rubinstein：首先，认知疲劳一词到底意味着什么？
汉斯·多克特：认知科学发现，认知工作有两种类型。因此，第一个是学习的、轻松的例程，您有输入和输出，并且有既定的编程来代替如何从输入到输出。你正在穿过森林，并没有撞到树木，但是没有学习发生，对吗？又如职业棋手开局。你可以在凌晨3点叫醒他们，他们就不会搞错开口了。
然后是第二种类型的认知工作，即需要所谓认知控制的任务。所以你有一个输入，你有一个目标，但你不知道如何实现这个目标。回到职业棋手，在某一时刻，可能性的空间呈指数级增长，这就是游戏的美妙之处。所以这不再是一个轻松的例行公事，现在你必须真正努力去赢得那场比赛，而这就是你大多数时候赢得或输掉比赛的地方。当谈到编写软件时，你需要认知控制。
有趣的是，习得的轻松例程并不会导致认知疲劳。你可能可以整天做开口，你可以整天穿过森林，你不会像，哦，我不再想出如何不撞到树;你的肌肉会感到疲劳，而不是你的大脑。但需要认知控制的活动会导致认知疲劳。我认为这真的非常值得注意。
我认为我们现在的软件开发就像 50 年前的体育一样，即没有痛苦就没有收获，痛得越多越好，对吧？看看勒布朗·詹姆斯和他的午睡。这并不是因为他懒惰，而是因为他想达到最佳表现。我认为在软件方面我们仍然以一种古老的方式看待大脑的工作，但这是同一件事，对吧？你需要了解自己的身体才能成为最好的运动员，所有的运动科学已经发展得如此之快，它已经彻底改变了比赛。这就是为什么勒布朗在 39 岁时仍然是世界上最好的球员之一。
DR：有趣的是，你知道，在我们工作的行业中，你所做的事情必须经过很多思考。当我创作一个故事时，我会进行采访、提出问题、思考和学习，到了一天结束时，我会精疲力尽。我的妻子说，你是什么意思，你整天坐在电脑前，怎么会累呢？这就是认知疲劳！你只想发呆一个小时，然后尝试恢复。
HD：令人着迷的是我们有这样的经验，我们有相应的条款。 “我累坏了，”“我精神疲惫。”有趣的是，目前我们只有对认知疲劳的生物学解释的假设。因此，他们做了一些新的研究，表明某些化学物质正在积累，即谷氨酸，当其达到一定浓度时，你的大脑就不再正常工作了。
DR：我们如何解决开发者的认知疲劳问题？
HD：首先，我想说，什么时候会出现问题？什么时候这不是问题？因此，如果我工作八小时，八小时后我的认知完全疲劳，但这会产生很多很棒的代码，然后任务完成，第二天冲洗并重复。问题在于，工作日发生的很多事情会加速认知疲劳，而不会带来更多产出。这就是问题所在，这就是我们必须解决的问题。
有些人谈论了很多关于流程方面的内容。上下文切换会加速认知疲劳，对吗？心理学中有很多实验需要不断地切换环境，这让人筋疲力尽。如果你按顺序做这个练习，你知道，10 个这种类型的练习，10 个其他类型的练习，你比一次做一个要有效得多。这背后确实有很多证据。
作为软件开发人员，有很多不必要的上下文切换，我举个例子。片状测试。我认为反思编写软件的一个基本事实非常重要：每一行代码都是一个假设。你无法从数学上证明这条线正在做它应该做的事情。这也不是人工智能的工作方式。同样，人工智能也会做出假设，对吧？拥有自然理论的物理学家，他们会做什么？他们通过实验与自然对话。软件工程师与工具链进行对话。嘿，编译器，你觉得怎么样？嘿，单元测试、功能测试、安全检查等等。这就是我们编写测试的原因，对吗？否则，客户必须提供反馈，而且反馈往往是负面的。
反馈可能需要五分钟、二十分钟、一小时、好几个小时，所以反馈周期很长。然后你必须开始做其他事情，或者你必须等待反馈。 Google 做了一些研究，发现开发人员对于需要不到 10 分钟的反馈周期，他们会等待。现在反思一下，对吗？人们可能会说，哦，懒人等等，但这实际上是避免上下文切换和优化生产力的主动策略。他们基本上是说，不值得为上下文切换付出代价，上下文切换的精神成本，这需要你在思考其他事情时改变大脑中的神经模式。
因此，这是一种生产力策略，说，嘿，这种权衡不值得。因此，当某件事需要九分钟时，您等待九分钟，当某件事需要四分钟时，您只需等待四分钟。如果你能把时间缩短到 40 秒，那么你只需等待 40 秒。
如果您询问大多数公司（例如财富 500 强公司），您的开发人员每天运行多少个反馈周期？一个反馈周期的平均时间是多少？他们失败的频率是多少？而失败的原因又是什么呢？这些都是非常简单的问题，我向你保证，几乎没有任何组织可以给你这些问题的答案。所以他们甚至不知道正在发生的最基本的事情。我对整个复杂的开发工具链的看法是，我们正处于 20 年前 Web 应用程序的阶段，当时我们还没有应用程序性能管理。你不知道购物车多久不工作，结帐需要多长时间，什么都没有。如今，不知道这一点几乎就像犯罪一样，但这就是我们在软件开发人员使用的机器方面基本上所处的情况。
