I’m always avoiding bear traps.

Sometimes I find one sitting in my throat, waiting to seize my words as I speak. In the middle of coding, I’ve had to sharply pull my hands away from the keyboard, barely avoiding a trap that’s appeared at my fingertips. I’ve found traps lurking at the front door before a run and on my seat before I meditate.

The traps are being set by their owner, and its name is perfectionism.

It can feel like perfectionism as a personality trait is a prerequisite for grand success, case in point Steve Jobs. Perfectionism is likely one of the most common humblebrag responses to that classic if awkward job interview question “what are your weaknesses?” After all, when you admit to perfectionism, aren’t you just admitting “I have to get everything right,” and isn’t that the path to success?

Perfectionism does not help us walk the path to success — instead, it’s constantly setting bear traps for us to step on.

So I can explain better, let’s roll with a definition. While not the first, here’s the one I’ve landed on.

Perfectionism is a maladaptive strategy for coping with fear, especially the fears of injury and judgement. The strategy is to never make mistakes, thereby shielding yourself from the consequences (injury and judgement) of mistakes.

Two important words in this definition are injury and judgement. “Injury” is the term I’m using for the material loss that happens from making mistakes. Site downtime caused by a buggy line of code I wrote or the money lost from a bad investment I made are examples of injuries. “Judgement” is the term I’m using for the social repercussions of making mistakes. When you make a mistake, you open yourself up to shame and embarrassment (two of the most uncomfortable feelings in existence).

To me, this definition strikes at the heart of why perfectionism is a hindrance. If you’re acting as a perfectionist, you’re not optimizing for success. Instead, you’re optimizing to avoid the mental pain of judgement and injury (which for perfectionists, can be quite strong). These are two very different objective functions, especially since success always results in some judgement and injury along the way. Successful, fulfilled people make mistakes.

Thus perfectionism is a futile struggle to avoid unavoidable unpleasantness. A constant battle to control the uncontrollable (particularly the opinions and feelings of others). The struggle eventually turns inward, becoming an internal battle to make yourself do anything. After all, if you’ll only act without mistake, but every action can be a mistake, how will you ever act? The only surefire way to avoid danger is to do nothing, and indeed the end result of perfectionism is often being frozen in place.

Perfectionism wants to protect me from twisting my ankle, looking stupid, writing code other developers could judge me for, or saying anything that might be taken the wrong way. So it puts bear traps at the front door, on the keyboard, and in my throat. If I want to try a new activity (especially one I don’t feel naturally good at) it’ll line the whole floor with traps. If one catches, I’ll be stuck in place and “protected” from the risky activity.

This is how perfectionism robs us of experience, which is a truly ironic tragedy, since experience is the only way we can learn to make fewer (or maybe just newer) mistakes. Bear traps hurt.

Perfectionism is driven by the fear of injury and judgement, but sometimes someone else’s opinion can seem a thousand times more frightening than a broken leg. This is especially true when the opinions of others can influence your career trajectory. In software engineering, we have a lot of problems around how we judge each other, which in turn impacts who wants to be and call themselves a programmer.

Jacob Kaplan-Moss, known for his work on Django, recently gave a keynote at PyCon 2015 discussing the “programming talent myth.” In the talk, he’s discussing how in software engineering we see each other either as virtuosos at the symphony or troglodytes in caves, with no space in between. This is a problem for many reasons, including that that “space in between” is the space we traverse as we learn and grow as engineers.

The programmer talent myth drives people to perfectionism, since mistakes can lead to judgement can lead to being in the cave with the troglodytes. Being on the wrong side of the myth is unbearable, not just because the exciting positions, talks, projects, and benefits go to the virtuosos. It’s unbearable because it represents an irreparable loss of basic professional dignity (not being seen as a “true” programmer/coder/hacker). The loss seems irreparable because in the world of the myth, that “space between” troglodytes and virtuosos isn’t there, and thus cannot be crossed.

In this environment perfectionism feels essential. You had better be holding a violin, even if you have to fake a concerto every now and again.

This myth-induced pressure to be perfect can weigh especially heavily on tech industry minorities. The industry has an image of what a “true” programmer is like, and those that don’t fit that image are often subtly prompted by peers to prove themselves. Perfectionism seems even more essential if you’re constantly being auditioned, and the resulting frustration is part of what drives some tech industry minorities from their careers early.

The programming talent myth is just that, a myth. In reality we all start by swinging our kludges wildly, each mistake taking us one more step toward the skill required to elegantly manipulate a bow. Behind every rockstar programmer is a long road littered with many buggy and inelegant lines of code. We can tackle many of the problems in our industry just by seeing each other as “on the road,” rather than as standing on one side or another of an artificial chasm. For starters, this will help us all avoid the traps of perfectionism when we sit down at the keyboard.

Perfectionism is antithetical to good engineering. Good engineering is about making smart tradeoffs, not dealing in absolutes. For any solution to any sufficiently interesting problem, there will be a list of pros and cons (which often change with time as project requirements evolve). Freezing in place to fret over the cons is counterproductive; intentionally selecting and accepting the tradeoffs is the only way forward. Coding with perfectionism in your heart is no way to code, while a little healthy fear topped with bravery can lead to genius.

The same can be said for life.