“Gumption traps” are a term introduced by Robert M. Pirsig in Chapter 26 of Zen and the Art of Motorcycle Maintenance as a detail of his Metaphysics of Quality. They’re probably one of the most approachable topics in that book, and also one that can be acted upon very quickly, even (or maybe especially) by beginners. A newcomer to software engineering, motorcycle maintenance or any other craft job will definitely find something there that they struggle with and that they can work on.

罗伯特·皮尔西格(Robert M. Pirsig)在《 禅学》和《摩托车维修艺术》的第26章中引入了“进取陷阱”，作为其质量形而上学的一个细节。 它们可能是该书中最容易接近的主题之一，而且即使是初学者也可以很快采取行动。 软件工程，摩托车维修或任何其他手Craft.io工作的新手肯定会在这里找到他们苦苦挣扎并可以从事的工作。

进取和进取陷阱 (Gumption and gumption traps)

“Gumption” is a Scots word similar to English “courage”, but its meaning is a little broader. Cambridge Dictionary defines it as:

“ Gumption”是苏格兰语单词，类似于英语中的“ courage”，但含义更广泛。 剑桥词典将其定义为：

The ability to decide what is the best thing to do in a particular situation, and to do it with energy and determination. “She had the gumption to write directly to the company manager and persuade him to give her a job.”

决定什么是在特定情况下最好的事情，并充满精力和决心去做的能力。 “她有直接写给公司经理的信条，并说服他给她一份工作。”

It also has that certain ring to it that, once you say it out loud a couple of times, will give you a better idea what it means.

它还具有一定的响度，一旦您大声说了几遍，就会带给您一个更好的主意。

Gumption in philosophy is not a particularly new idea, Aristotle hinted to something of that sort in Nicomachean Ethics as the difference between potential and result. Gumption is that difference. A doctor, for instance, can have the necessary skills to save the life of a bleeding out patient in front of him, but without gumption — without the drive to actually put those skills to use — the patient will die.

进取心的理念是不是一个特别新的想法，亚里士多德暗示到那种在尼各马科伦理学一些潜在和结果之间的差异。 固执己见就是与众不同。 例如，医生可以拥有必要的技能来挽救流血的病人，但如果没有勇气-没有实际使用这些技能的动力-病人会死亡。

As Pirsig puts it:

正如Pirsig所说：

Gumption is the psychic gasoline that keeps the whole thing going.

脾气暴躁是使整个事情持续进行的精神汽油。

Gumption is essential in any kind of craft — be it woodworking, motorcycle maintenance or programming. Within the context of programming, you will see gumption differently based on whether you’re working on a project of your own or a commercial project for a customer. The gumption traps will be the same, just the ways of dealing with them might be slightly different and your approach might require different kinds of adjustments.

在任何类型的Craft.io中，无论是木工，摩托车维修还是编程，进取都是至关重要的。 在编程的上下文中，根据您正在开发自己的项目还是为客户进行的商业项目，您将看到不同的进取心。 进取陷阱将是相同的，只是处理它们的方式可能略有不同，并且您的方法可能需要进行不同类型的调整。

What is a gumption trap then? It’s a factor, either external or internal, that causes your gumption to “leak out”. It’s when the relationship between the craftsman and the material he is working on breaks. The result of falling into a gumption trap is the loss of enthusiasm of working on the material and the irresistible desire to put the entire thing away. Since we are talking here primarily about programming, we will be discussing these mostly within that context.

那么什么是进取陷阱？ 这是一个外部因素或内部因素，会导致您的进取精神“漏出”。 此时， 工匠与他所加工的材料之间的关系中断了 。 陷入困境的结果是对材料进行工作的热情下降，以及无法将整个东西收拾起来的不可抗拒的愿望。 由于我们在这里主要谈论编程，因此我们将主要在此范围内讨论这些内容。

There are, broadly, two groups of gumption traps. External, that is arising from the material (in our case, code) itself, from the system we are working on, from the external parts (libraries) that we use or from something else. Pirsig calls these ”setbacks”. The second type — internal — is caused by our own poor mindset or failures in performing our craft. These are called ”hangups”. Hangups are further divided into three groups — “value traps”, “truth traps” and “muscle traps”.

大致上有两类防暴陷阱。 外部的，它是由材料(在我们的情况下为代码)本身，我们正在研究的系统，我们使用的外部零件(库)或其他任何东西引起的。 皮尔西格称这些为“ 挫折 ”。 第二种是内部的，是由于我们自己的不良心态或执行Craft.io失败所致。 这些被称为“ 挂断 ”。 挂断进一步分为三类：“价值陷阱”，“真相陷阱”和“肌肉陷阱”。

挫折 (Setbacks)

Setbacks are external gumption traps and most often arise from the material the craftsman is working on or other external conditions. They may also come up as a result of something you have done previously.

挫折是外部的陷阱，通常是由工匠所使用的材料或其他外部条件引起的。 它们也可能是由于您之前完成的操作而出现的。

乱序重组 (Out of sequence reassembly)

Does this happen to you, that you work on a complicated feature, but just in the end, as you’re about to wire everything together — and maybe connect the UI to the back-end you discover that there’s a mismatch on the interfaces and you need to rewrite one of the sides entirely? Or it turns out that the feature is not exactly up to spec because you missed something and now you have to start over?

这是否发生在您身上，您使用的是复杂功能，但是最后，当您要将所有内容连接在一起时–也许将UI连接到后端时，您会发现接口和接口之间存在不匹配。您需要完全重写其中之一吗？ 还是事实证明该功能不完全符合规格，因为您错过了某些东西，现在必须重新开始？

That’s the trap of doing things out of sequence. In more general terms, it’s when you realise you did something based on incorrect facts. Sometimes those facts change as you work — it’s even more disheartening then. But there are ways to deal with it.

那是做事混乱的陷阱。 用更笼统的术语来说，就是当您意识到自己是根据不正确的事实做了某件事时。 有时，随着您的工作，这些事实会发生变化-那时更令人沮丧。 但是有很多方法可以解决它。

The first one is to be meticulous about your presuppositions. In other words — plan ahead. Not too much — there will be facts that you will fish out once you start working on it — but think about the general, high-level requirements that you will be working with. Read the spec of the feature a few times, note down (either physically or mentally) what jumps out at you as incorrect, under-communicated or what might prove to be more difficult later on. The knowledge of how to do that comes with experience — but the more attention you pay to it, the quicker you will gain that experience.

第一个是要谨慎对待自己的前提。 换句话说-提前计划。 太多了-有事实表明，一旦您开始进行这项工作，您就会发现问题-但请考虑将要使用的一般性，高级要求。 几次阅读该功能的规格，记下(无论是在身体上还是在精神上)是什么让您跳出来是不正确，沟通不畅，或者以后可能会变得更加困难。 如何做到这一点的知识随经验而来，但是您对它的关注越多，您就会越快地获得经验。

Secondly, commit often. If you don’t use a version control system, start. And then whenever you finish a logical chunk of work, commit. This leaves a paper trail and a quick and easy fallback mechanism to return to in case your preconceptions turn out to be wrong.

其次，要经常犯 。 如果您不使用版本控制系统，请启动。 然后，只要您完成逻辑工作，就提交。 如果您的先入为主的想法是错误的，那么这将留下笔迹，并提供一种快速简便的回退机制。

And finally, when you do finally end up falling into this particular trap, remember that the subsequent “reassembly” — rewriting of the incorrect modules — will most likely take far shorter than the first run. After all, you already have the necessary knowledge not to make the same mistakes.

最后，当您最终陷入这个陷阱时，请记住，随后的“重新组装”(重写不正确的模块)最有可能比第一次运行花费的时间短得多。 毕竟，您已经具有必要的知识，不会犯同样的错误。

间歇性故障 (Intermittent failure)

…or as they’re called more commonly in our field: heisenbugs. These are issues that seemingly disappear when studied. They exist only in production, but when we take the magnifying glass of our debugging tools, they are nowhere to be found.

…或者在我们的领域中更常见的称呼是：海森虫。 这些问题经过研究似乎消失了 。 它们仅存在于生产中，但是当我们使用调试工具的放大镜时，就找不到它们了。

Unfortunately, if the heisenbugs were not as pernicious as they are, they would not be so feared. The advice Pirsig gives to deal with them in the context of motorcycles — “just ride it out” for a couple hundred kilometres — is also difficult to action within the software context.

不幸的是，如果heisenbug并没有那么有害，就不会那么害怕。 皮尔西格(Pirsig)提出的在摩托车环境中应对这些建议的建议-“只是骑了几百公里”-在软件环境中也很难采取行动。

Fortunately, the programming languages of today provide us with a host of tools to catch these bugs — but problems start when you do not exactly know how your diagnostic tools work.

幸运的是，当今的编程语言为我们提供了捕获这些错误的大量工具，但是当您不完全了解诊断工具的工作原理时，问题才开始出现 。

One story from my professional experience comes to mind here. My colleague was trying to debug an object that seemingly had incorrect properties appended to it — but whenever he put a console.log into the function that constructed this object and inspected its nested properties, everything seemed to be fine, even though the result of an Excel file that was later generated by the object was blatantly wrong.

从我的专业经验中得出一个故事。 我的同事正在尝试调试似乎附加了错误属性的对象，但是每当他将console.log放到构造该对象的函数中并检查其嵌套属性时，一切似乎都很好，即使该对象后来生成的Excel文件公然错误。

The issue, turns out, arose from a peculiarity in how console.log works in browser dev tools (which I’m sure my esteemed colleague knew about, but just happened to forget when it was needed — it happens to the best of us). Namely, the nested properties of an object are reevaluated when opened inside the browser dev tools. So, when one logs an object in a given state, if it had mutated by the time one opens one of its nested properties, those nested properties might not be the same as they were at the time of logging the object. (We had to mutate the object for performance reasons.)

事实证明，这个问题源于console.log在浏览器开发工具中的工作方式的特殊性(我确定我的尊敬的同事知道这一点，但是只是偶然地忘记了何时需要它-它发生在我们当中) 。 即，在浏览器开发工具中打开对象时，将重新评估对象的嵌套属性。 因此，当一个人以给定状态记录一个对象时，如果它在打开其嵌套属性之一时已经发生了变异，则这些嵌套属性可能与记录该对象时的嵌套属性不同。 (出于性能原因，我们不得不更改对象。)

The solution in that case was to console.log(JSON.stringify(object)), however we did spend a good workday trying to figure that out. The bottom line - remember how your diagnostic tools work.

在这种情况下，解决方案是console.log(JSON.stringify(object)) ，但是我们确实花了一个好工作日试图找出console.log(JSON.stringify(object)) 。 最重要的是- 记住诊断工具的工作方式 。

零件挫折 (Parts setback)

We do not often think about having to replace parts in a program — after all, it’s not a physical thing, and the code that we write doesn’t experience wear and tear, right?

我们不必经常考虑必须替换程序中的部件-毕竟，这不是物理上的事情，而且我们编写的代码不会遭受磨损，对吗？

Wrong. Our code uses (especially in the JS ecosystem) various kinds of libraries and modules. Some of these modules we wrote ourselves, some are third-party. Those third-party modules are often a source of our woes. Sometimes an update is going to break it. Sometimes there will be a bug in third-party code that we can’t exactly fix. Sometimes we will simply outgrow the needs of a library. Another time we will have to replace one component with another that does not have the same interface.

错误。 我们的代码使用(尤其是在JS生态系统中)各种库和模块。 我们自己编写的某些模块是第三方的。 这些第三方模块通常是我们苦恼的根源。 有时更新会破坏它。 有时第三方代码中会有一个我们无法完全解决的错误。 有时，我们只会超出图书馆的需求。 下次我们将不得不用一个没有相同接口的组件替换一个组件。

The most straightforward way to deal with these issues is to wrap your third-party code in custom interfaces. When you import a React component, do not simply use the provided interface that it ships with and then use it in dozen pages. Instead create a single point of contact between the library and your code. Oftentimes it might just be a rewrite of the module’s interface into your own code — but that step is very important. Because when the time comes to replace that component, there will only be one place to change the interfaces rather than a dozen.

解决这些问题的最直接方法是将第三方代码包装在自定义界面中 。 导入React组件时，请勿简单地使用它随附的提供的接口，然后在十几个页面中使用它。 而是在库和您的代码之间创建一个单点联系。 通常，这可能只是将模块接口重写为您自己的代码-但是这一步非常重要。 因为当需要更换该组件时，只有一个地方可以更改接口，而不是十二个。

Of course this all has to be done within the bounds of reason — if you import React itself, it is fairly pointless to write an entire interface around such a robust framework. If a time comes to replace React, you will have bigger problems than that.

当然，所有这些都必须在合理的范围内完成-如果您导入React本身，则围绕这样一个健壮的框架编写整个接口是毫无意义的。 如果需要更换React，那么您将面临更大的问题。

And also, remember to sometimes ask yourself the question “can’t I make this myself?“. Homegrown components are not in any way worse than third-party ones and the time spent building one of your own can save a lot of headache in maintenance. It’s also much more flexible and gives you more experience to approach similar issues in the future. Finally, since we live in the digital world where every piece of code can just be copied or imported indefinitely, you might very well use that module in the future.

而且，请记住有时要问自己一个问题：“我不能自己做这个吗？”。 本地生产的组件丝毫不比第三方组件差，并且花费自己的时间来构建自己的组件可以节省很多维护方面的麻烦。 它也更加灵活，可以为您提供更多的经验，以便将来处理类似的问题。 最后，由于我们生活在数字世界中，每段代码都可以无限期地复制或导入，因此将来您可能会使用该模块。

结论 (Conclusion)

Setbacks often feel unfair — they come from things that we do not have much control over. But we do have control over how we approach them.

挫折常常让人感到不公平-他们来自我们没有太多控制权的事情。 但是我们确实可以控制我们如何处理它们。

Check back next time for part two, where we will consider another kind of gumption trap: hang-ups. Or, in other words, the things that are all your own fault.

下次再来看看第二部分，在这里我们将考虑另一种类型的陷阱：挂断。 或者换句话说，都是您自己的错。

继续阅读 (Continue reading)

You can read the Part Two of this series, as well as many other insightful posts, on my blog intercaetera.com.

您可以在我的博客intercaetera.com上阅读本系列的第二部分以及许多其他有见地的文章。