Reading Time: 19 minutes

The term imposter syndrome describes the feeling that you’re not qualified to be doing what you’re doing. It gets a lot of mileage in the tech community because most developers do feel this way at some point.

Unfortunately, though, we accidentally use the term to diagnose two very different phenomena that both contribute to tech workers feeling this way.

First, imposter syndrome covers someone’s impression that they’re not qualified for their position, even if they are, because they’re too hard on themselves or too generous in their assessments of the skills of their peers. This totally happens: I often focus on my mistakes more than my successes, and there is work that I can do to counter that skewed narrative in my head.

But there’s something else that contributes to folks not feeling qualified for their position: the very real impression of poor performance that they get when cocky or insecure coworkers treat them like a burden or condescend to them.

That’s not in their head. So to call it a “syndrome” inaccurately suggests that they suffer from a mental distortion. They don’t: they’re correctly reading signals that their colleagues send them.

So yes, maybe lots of tech people—senior, junior, privileged, marginalized—experience that first thing. But no, they don’t all experience that second thing, and no, they’re not all getting that as bad as everyone else, and no, there isn’t something wrong with you if you’re interpreting coworkers’ behavior as an indication that they see you as an imposter. (And yes, if you’re from a marginalized group you put up with this behavior more—and for longer—than your privileged counterparts.)

I want to provide an example for you of a situation where both of these things were at play, to some degree. So, I’m sharing with you the story of my first programmer job. Can you identify the parts of this story where “imposter syndrome” was all in my head? How about the parts where I was correctly picking up on signals that people saw me as an imposter?

Years ago:

I had a contract-to-hire position as a software engineer at a consultancy, and I just knew I would get hired. My boss had given me excellent feedback (He’d greet me in passing in the halls with a fist-pound and an enthusiastic ‘Crush software!’): he only needed to see me work on a client project (rather than an internal one) before he could extend the offer, and he would be putting me on a client project in the coming weeks.

I got rotated onto the client project. On this project, I pair programmed (two people programming together at one computer) for eight hours a day with a guy we’ll call Joe. Joe became a computer programmer in his mid-teens over twenty years ago, which made him more experienced than almost anyone in the office. Joe also has a habit of complaining about things, often with the expectation of getting a laugh.

I took Joe’s viewpoint very seriously: I listened to what he said, and I did not question his technical decisions. After all, Joe knew what he was doing: he didn’t seem to want outside interference as he worked, especially from a greenhorn like me. Sometimes he described code or coding tools as “stupid” or “terrible,” and this made me uncomfortable.

Feedback

After about a month of pairing with Joe, my boss (yeah, the ‘crush software’ one) took me into his office and informed me that the company would not be hiring me right away. He said my skills were not progressing. Also, he had feedback from my pair that I did not pay attention. I needed to assert myself more at the pairing station, he said. The conversation made me feel sad and insecure, but I did have a remaining chance: the company would extend my contract for another two months, and we would see if I got up to speed during that time.

So I began attempting to assert myself more at the pairing station. The first time I did so, I made a meek suggestion that Joe blew off. I shut up: after all, he knew better than I did. Later, though, I kicked myself for not trying harder.

Next time, I tried to be more firm. I got blown off upon making my suggestion. So I defended it: I briefly explained why I wanted to do what I wanted to do. I got shut down again. So I zipped it, proud of myself for having tried twice instead of once to make an impact on the code this time.

The third time, Joe referred to my suggestion as “a terrible idea.” That time I didn’t push it. I did ask my boss for help. He suggested I take Joe into a room and confront him about the situation myself.

So I remained meek at the pairing station, making technical decisions only when Joe was not at the computer with me. Luckily, this had been happening more and more lately: Joe had begun taking a rash of sick days and showing up to work an hour or more late with increasing frequency. At first the prospect of coding without supervision terrified me: what if I messed it all up? But as I got to place my hands on the keyboard more, to move at my own pace and not a blindingly fast one, I began to feel a strange, unsanctioned relief when I realized Joe would be late again. I liked having the opportunity to code without feeling like an adversary or a burden.

Yelling

It was a Thursday at about 2 PM. The issue this time had to do with an iOS layout that had given us significant trouble over the past few days. I decided to make a suggestion about the design of the code. My proposed method, while not standard for the type of screen we wanted to construct, would avoid a lot of duplication and workarounds that Joe’s solution would require. Even Joe hated Joe’s solution, so I figured my idea might interest him. Joe, however, reacted negatively to my suggestion with such speed that he practically seemed physically allergic to it.

But dammit, my job depended on me becoming more “assertive,” so I decided that now was the time to shit or get off the pot. I pushed the suggestion back at Joe, with justification. He pushed it away again as “wrong, just wrong.” I asked that we timebox our efforts and at least give it a try.

Then, Joe stood up and shouted down at me.

I don’t remember exactly what he shouted down at me. I only remember my face burning as I got out of my chair and speedwalked to the office door. I needed a break from the situation, and I needed a break from my pair. I took the elevator to the first floor, ordered a coffee from Starbucks, and cried silently into my sleeve as I waited for my drink. Then I trudged back upstairs and sat silently, sipping my coffee, watching Joe blaze forward on his own proposed path while listening to him lament and insult it with every keystroke.

After work, I had received a text message from another coworker, Jared. Across the office, he had heard the fight and he wanted to know if I was all right. Another coworker approached me in person after work and offered to bring it up to my boss, if I wouldn’t. I shrugged. She told me to think about it and let her know the next morning.

Switching Pairs

The next day I decided to tell my boss myself. So I walked into his office and informed him that, if he needed to see Joe view me as a peer before he would be sure he could hire me, then he would be waiting forever, because it would never happen. To my surprise, he nodded and said he knew: evidently, someone had clued him into the tension coming from Joe’s and my corner of the room. I would be rotated off the project immediately, he promised. Instead, I would go back onto the internal project I came from. If my pair partners on that project had good feedback for me, I would be hired. I felt vindicated, and I walked out of the office smiling.

On Monday, I started back on the other project. My pairs on this project included a guy we’ll call Dave and another guy we’ll call Mike. Dave had led this project for about five months, and Mike had rolled onto it about three months prior. Mike admired and revered Dave: Mike would not commit code without having Dave look at it. This made things difficult two weeks later, when Dave was rolled off of the project to help spin up a new project and Mike was left in charge without Dave.

That period must have been stressful for Mike. Mike could no longer lean on Dave to okay his code. The last thing Mike felt he needed, during this stressful time, was my inexperienced self mucking up the code base. He preferred to solo, so he would stick me on a different computer where I would attempt to pick up tasks on my own. Whenever I finished one of these tasks, I would return to Mike to let him know. Mike would come over to my computer to look at it. Then he would say:

“Okay, let’s throw this on a branch. I’ll start this over later.”

It took all of two days before he stopped looking at my code at all. It became his habit to throw my work on a branch and leave it there.

I wondered: was I this bad at code? If so, maybe I shouldn’t be a programmer at all. Maybe I had gotten in over my head: maybe I just wasn’t smart enough to become a programmer. I didn’t know enough, and my pairs viewed me as dead weight. I couldn’t do it. My boss confirmed my fears: evidently Mike didn’t have hire-worthy things to say about me, either. Now my boss, too, felt scared: in his mind I represented a risk to his business. He had one more project he could try me on: an Android app for another company, the project Jared worked on. But this project wasn’t like the other two I had done: it wasn’t internal, and it wasn’t for a non-technical, laid-back client like the one I worked for with Joe. These clients came into the office every day and worked closely with the programmers. Oh, and they demanded a lot.

My boss needed that project to succeed. He had come to Chicago to start this office, and the Android project could mean a huge contract for the company. That project had generated a lot of excitement high up in the company, and it belonged to his office. Putting me on there represented a big risk. He took me to a coffee shop to inform me that he didn’t think he could put me on it. That would mean that, in ten days, when Mike’s new pair started, my contract would end, and it would not be renewed. I should start looking for another job.

The Search

I contacted friends and mentors, who immediately suggested contacts at a few companies around town. By Friday, I had arranged an interview with one of them over my lunch hour. I rushed out of the office at 12:01 to jog to their office. One full plate of extremely spicy Ethiopian food later, the company’s director informed me that I could submit my resumé through the website if I wanted to. I jotted some notes and ran back to the office. I made it back through the door at 1:01. Whew. No one would be suspicious…I thought.

I walked into the kitchen at 3 PM to wolf down a yogurt. The work day had proven particularly frustrating so far. Mike continued to undo and ignore my work, but that day it wasn’t even code—it was Github documentation.

Evidently Mike found my command of the English language substandard.

As I rounded the corner to whip open the refrigerator door, I walked past Jared eating a bowl of oatmeal.

Jared had missed me at lunch. He wanted to know what had happened.

So I told him about my project and about my conversation with my boss.

“What do you want me to do?” he asked.

I shrugged. “I don’t want you to do anything. You wanted to know. I’m answering the question.”

Advocacy

At about 4:30, I noticed motion out of the corner of my eye. I looked over. Behind the glass wall of my boss’s office, Jared gesticulated at my boss. My boss looked contemplative. The conversation continued past the end of the work day.

Later that night, Jared texted me to ask what was up. I responded somewhat rudely with some reference to my horribleness at coding. He told me about his conversation with my boss. He was fighting to get me onto the project. “But if I can even get you on, you’ll have to know your stuff,” he warned me. He ended up giving me a book with a tiger on the front and the title Java in a Nutshell. “Read this. Skip the chapter on lambdas: we’re on Java 7, and it doesn’t have those.”

For the next week in our spare time, Jared would code with me after work: sometimes on the client project for a few minutes, but mostly on random Java. He would thumb through the book and drill me on various concepts. I studied as if I already knew I would be on that project, even though I knew my boss had said he would likely not put me on it.

The following Wednesday, my boss pulled me into his office. I walked in to find him and Jared sitting down. My boss informed me that he would, in fact, put me on the project. He had extended my contract by four weeks. But this was it. If I couldn’t demonstrate the requisite progress in these four weeks, he had nowhere else to rotate me. That would be the end of my time at the company.

I said I understood. I walked out of the office. After work, I went right back to studying with Jared. He explained the app’s code base to me—both the client side and the server side—and explained to me how to draw a picture of this structure. I followed the instructions and ended up with a couple of diagrams in a purple notebook, each one a web of circles and rectangles connected by arrows and labels.

The Challenge

The following week, I rotated onto the Android project. I felt, on that first day, as if I were walking to my execution: somehow a total calm had spread over my body, as if I had come to terms with the fact that this was my final chance. I paired with Jared for the first two days. He showed me around the code base, and he forced me to do all the typing. By now, I had become decent at the keyboard shortcuts. I could not drive nearly as fast as he could, but I did not drive slowly, he said.

“Honestly? Be honest. Do I drive slowly?”

He looked at the ceiling, then looked at me. “No.”

For the next two days, I paired with another guy on the project who we’ll call Marcus. Jared warned me that Marcus did not like to be forced to drive the entire session. So I jumped in early and often. I tried to contribute. Marcus had to show me many things about the code base. I still didn’t get it all.

I would express this fear to Jared many times over the next few weeks. “Jared, I don’t think I’m getting it. I don’t think I’m learning it fast enough. I don’t think I can do this.”

Jared would reassure me, but I continued to repeat this worry to him ad infinitum. Finally, he leveled with me: “So you can stop trying, or you can keep trying. That’s all there is.”

The next morning, I woke up an hour earlier than usual and walked into work at 7 AM to look at the app code for an hour before the work day started. I got almost nowhere, but this hour of time before work became my habit. I began to bring in the purple notebook to scrawl on the pages behind my circle-arrow diagrams from a few weeks prior. During that hour, I would choose a completed feature from the previous day, go into the code history, and look at the commit labeled for that feature. Then I would thumb through all the new code written to implement that feature, and I would write down which methods and variables had been added and changed in which files. I would make little notes about why the changes had been made and how the files worked, if I knew.

Slowly, I felt myself learning my way around the app. I could start to drive more. I could start to speak up more. Though I remained quiet compared to the senior developers on the project, I managed to contribute…at least, I thought.

My Evaluation

My final week on the project arrived, and I suspected that my boss had forgotten about me. Between a flurry of new projects and new hires, I wondered whether I had fallen through the cracks. I floated this idea to Jared on Wednesday morning of that week.

Two hours later, my boss began asking the other developers on my project to step into his office for a minute, one by one. I suspected immediately that he was collecting feedback on me. I felt, shockingly, not nervous: not because I felt confident in my programming ability (by God, I do not), but because I felt that I had genuinely tried as hard as I could. If I did not make the grade, it would be because I genuinely could not have done it—not because I could have and chose not to.

The next day, my boss called me in. He sat in a chair next to his table. On the table sat a piece of paper with the company logo on it. The rest of the text on the paper described a job offer.

Fast-forward:

I took that job offer, and three months later I ended up anchoring that Android project. After that, I went on to anchor various other mobile projects, including a dual-platform (Android and iOS) mobile app with 11 million users. I worked for the company for another two years. When I left, it was my choice.

Yes, I felt imposter syndrome. You can see examples of it in the story: I worried that I drove slowly, even when someone told me I didn’t. I worried that I didn’t work hard enough. I felt like maybe I wasn’t cut out to code in the first place. But that story also contains several events that illustrate my point about imposter syndrome: the feeling wasn’t all in my head. I had Joe, Dave, and my boss, among others, driving me toward the conclusion that I could not do this work.

If your response to this story was ‘Oh my gosh, that’s my life’:

My recommendation is to find an advocate. I had an advocate, and that helped a lot. If you cannot find one right away, or you cannot find one at your current company, that is OK. You may be able to reach out to programmers you admire on Twitter or LinkedIn who can mentor and assist you in general, if not at your specific job. You can also rack up time with a ‘developer’ title, and then switch to a company where you can find an advocate.

If your response to this story was ‘Wow, that has never happened to me’:

Please keep this in mind the next time someone is confiding what sounds to you like a case of imposter syndrome: what they’re experiencing might not be what you, a person who sometimes doubts yourself but are generally supported at work, have experienced. It may not be accurate for you to treat your experience as an instructive example for them. Also, if you can advocate for the person who is experiencing this, please do. We need more people like you doing that in the workplace.

Conclusion

We talk about imposter syndrome as this thing every tech worker experiences. To some degree, yeah: lots of people are unfairly hard on themselves about their work. But there’s this other piece going on, which is the piece where people experience behavior from their coworkers that encourages them to feel like an imposter.

When we look at a play-by-play of my initial experiences as a programmer, we see more examples of the latter than of the former.

It’s important to keep that in mind: other people treating you poorly are not ‘all in your head.’ You can counter their narrative some by identifying advocates. And if you have never or rarely experienced coworkers making you feel like an imposter, you do the tech community a service by becoming an advocate for someone who does experience that.

If you found this piece helpful, you might also appreciate:

This rubric for evaluating and encouraging inclusive behavior at work

This piece about the seeds of a great company culture

This piece about the role of anger and sadness in a work environment