Imposter syndrome is often presented as a personal failing. A lack of confidence, our wrong-headed beliefs not matching the reality of how competent we are, or worst of a flaw of our gender. Just tell yourself you are wrong! Imagine everyone else is just like you! Have confidence in all parts of yourself except that part that tells you not to have confidence!
Unsurprisingly, these interventions are not often effective. At best, they change behavior, frequently while making people who already feel bad about themselves feel worse. At worst, they lead people to stop trying to improve the environment they have found themselves in.
I would like to offer an alternative story: imposter syndrome is a rational response to insufficient feedback.
Until I joined TripAdvisor I had no real way of knowing whether I was a good programmer. I knew that often our customers were happy, but that was often three to six months after I wrote the code. I knew that sometimes I couldn’t make something work, and I assumed that was my fault whether it was or not. I sometimes knew I was grateful to be working in my own code months later and sometimes I wasn’t, but again that was far from where I had made those decisions and it was only my own opinion. I was anxiously waiting to be discovered and dismissed. I covered with appeals to good engineering principles I had heard about, largely ignored by the people around me.
Without feedback, there are three options: I can believe, without evidence, that I am an awesome programmer. I can believe, without evidence, that I am a terrible programmer and quit to go do something else. Or finally, I can believe, without evidence, that I am a terrible programmer somehow successfully pretending to be an awesome programmer.
The problem with believing, baselessly, in one’s own competence is that eventually we all reach the limits of our capabilities. Suddenly confronted with evidence of their lack of perfection, overconfident people become defensive and blame anything other than their own failings for the problems, making them impossible to fix. Any evidence of failure becomes personally devastating. It is hard to protect one’s self from any possible feedback. Among programmers, I often see such people retreat into believing that they are this nebulous category known as “smart” and that “smart” is always enough to do anything. These people appear deeply confident, but their confidence is a protective illusion and the cost is born by the people around them who have to protect their fragility.
The people who take the second choice and drop out simply disappear. They never have a chance to find the feedback they were missing, but they also don’t have to confront their personal insufficiencies. Personally, I certainly wasn’t going to drop out. Until I became a programmer I was making $27,000 a year as a hospital manager. I might not be good, I figured, but I was good enough to bring home my paycheck.
The genius of imposter syndrome is that it is adaptive and self-perpetuating. We don't have to disregard when we fall short, for such failures fit our internal narrative. Failure is a terrifying chance to be found out, but it is not an existential challenge. When we succeed, we can believe it is part of our act. Look how well I have fooled everyone by doing work they think is good! We often work hard, to cover for our obvious faults, and may take into account the possibility of human failures, which inevitably occur, both of which can produce decent results.
However, these successful results come at significant cost. We have trouble accepting real feedback, since any feedback is based on our facade and we “know” better. Imposter syndrome also brings with it anxiety and shame, preventing us from feeling the thrill of accomplishment when we do succeed. It robs us of the joy we earn.
When I joined TripAdvisor I found that all code was code reviewed. On my team we required three ShipIts to commit code, so at least three people had to read any code I wrote. It was absolutely terrifying to post my first code review. My first real project took a month, and I was panicking over my failure to deliver in the estimated time. I was working in all brand-new languages, in a brand-new domain: I didn’t ask questions because I didn’t even know what questions to ask. Instead I sweated and tried things out and Googled madly. At last the day came when I couldn’t put it off anymore and I posted my review.
Naturally, it being the first thing I had done as a web developer beyond bug fixes, I got back pages of comments. And then… the world didn’t end. I addressed the comments. I got ShipIts. The project worked. I moved on to the next thing. Next time, I had learned the coding conventions and how scope worked in JavaScript. The time after that I finally understood closures. On and on, my stupidity was laid bare for the world to see and it turned out it didn’t matter. No one cared, and when I took the feedback on board for next time they thought it was awesome. It wasn’t that we were all covering for how bad we were at our job: it is that we were all plenty competent and becoming more so. The flaws we had weren't disastrous because they were accounted for by the system.
Eventually I began learning to teach, to provide effective feedback and create a shared vision of what “good” code looked like. I built up the people around me, as they built me up.
After a few years of that, I realized I no longer imagined I was bad at my job. With no place to hide, I would have been found out years ago. Also, by this point I was significantly more effective, and the people around me were too. None of us were some binary “good coder” versus “bad coder”: we were all coders, with things we did well and places we struggled and areas where we were learning. I realized that I was a "good coder" not because my code was aways right or always worked straight away, but because I had processes I followed to ensure that my code became right and worked before being released and communicated clearly my intentions to my collaborators. I started to look for other feedback mechanisms: aesthetics and unit tests and pair programming for code, shared values and professional belonging for our team, manual testing and user experience feedback and analytics for our products.
Once I got to this state, it no longer mattered whether I was “good” or not. I became part of an effective team, and together we made useful things that satisfied our users' needs. They were easy to experiment with, extend and maintain. Anyone who looked at that and thought what mattered was whether we were “smart” seemed to me to be asking the wrong question.
The cost of imposter syndrome is shutting ourselves away from the very thing that could cure it. It becomes a trap. It prevents us from becoming improving where we could improve. It keeps us from connecting with our collaborators, with whom we can accomplish greater things than even the best programmer could do alone. These stories we tell ourselves to get by strangle our true voices, and in silence there is only fear.
I have at times offered the advice of “Be Brave”, but I now believe that is not quite right. I try instead to be curious when confronted with fear. When I find that I am afraid, I poke at it, prodding for information, finding what feedback I am missing. When I am done I can still choose to do the things I was afraid of, only more safely because I know more. Sometimes what I learn is that this is not something to do, and I set it aside. Fear points the way to all the most interesting things, and when we are safe and secure we can use it as that tool.
I believe that the reason so many underrepresented programmers feel imposter syndrome is two-fold. First, we seldom have the option of being baselessly overconfident while those around us protect us from the truth lest we throw a tantrum, so in the absence of feedback we can choose between imposter syndrome or quitting. Second, we have been deprived of some of the pathways others can use to get easy feedback and reassurance. We can not look around and be automatically reassured of our belonging. We get feedback that is extraneous to our actual job while too often lacking the casual feedback among peers about our work. We can't simply follow the cultural conventions we already know and be accepted. When we are busy responding to feedback that is about our very selves, we cannot build the professional confidence that protects us when we seek out feedback that lets us improve the craft. When we are rendered invisible and ignored, we have stolen from us the opportunity to build true confidence. This does not imply that is is a problem exclusive to those who are underrepresented, nor that all underrepresented developers feel this way. It is simply understandable that this adaptation would be more common. Until we can offer everyone who want to program inclusive and effective forms of unavoidable feedback there will continue to be disparities in experiences based in how people are regarded.
There is a way through imposter syndrome and out the other side, into confidence based in knowledge and not delusion. I have personally found this a more satisfying approach than merely telling myself other people have felt the same. I no longer fear being discovered to be a bad programmer. I am no perfect coding machine, but no human will ever be so. I strive to know my weaknesses, and find ways they can be valuable. I seek or build contexts where I can be most effective and have the most impact. The most important piece of that is getting feedback on whether what I am doing is the right thing to do, early and often and unavoidably. There is always more work to do, and we can never be “good” enough to do it all.
By accepting feedback we can all be constructive, and that is sufficient.