The Dangers Of Imposter Syndrome in Technology Today

Eric Schles
Aug 8, 2017 · 4 min read

I am a bad programmer. This is the most dangerous phrase in technology today. It undermines everything about us. It makes the things we fought so hard for worthless. All because criticism is hard to take and we don’t honor that. Pushing back our emotions and believing all criticism makes the work better.

I believe there are two forms of bias that propagate through developers, those that believe themselves the best and those that believe themselves the worst. Until recently, I feel into the category of feeling like I was the worst. This is because I’m a pessimistic person, in general, and so I have a tendency to believe bad things. But now I realize, I am not the worst, at least at programming. In fact, I think I’m pretty damn good at it.

I believed I was bad because something happened, I started working for a place that does code review. Before that I’ve never worked at such a place. Everything got merged into master and if there were bugs, we fixed them later. That’s because until now, I have always worked on code that saved lives, in the social justice space. When someone’s life depends on you, you don’t have time for code review. Also, that’s not a job most folks want, so you don’t exactly have colleagues. Most people can’t handle the pressure or simply don’t want the pressure. Personally? I think this is exactly where we should be spending our time automating. It’s sad to me that the most important work is often still done solely by people. They should still and always be a part of the work. But we have automation for a reason, to make people’s lives easier. Shouldn’t we be making the folks who’s jobs it is to save us in times of trouble, as easy as possible? But I digress.

When I was saving lives, the code flowed from me. I could easily write 14 or 15 million lines of code a year under those conditions, because the work was too important. Things needed to get done or people died. So I did those things. I didn’t learn “best” practice, but I learned how to go from idea to a deployment in less than 18 hours. If I took more than 3 days to be useful to the person who needed the thing I was making, it was because I had a cold.

This was my first 5 years of software engineering experience. I developed some opinions not shared by other, because I was usually doing this work alone. And I’m okay with that. But it’s not optimal. There are things I did that made my life harder for myself. And there are things I did that no one else could understand. These are real problems, because I won’t have just one job the rest of my career. But I took it to mean, when folks started reviewing my code, that I was dumb. That I didn’t know what I was doing. Not the first time someone reviewed my code, but most times after that.

if you pour enough water over a mountain, it too becomes a stream. Believing I’m not good enough, because others were reviewing my work is the problem. And it’s not that they found errors. It’s that I believed this implied I was not intelligent.

Code review and self respect are like two sides of a balancing act — too much code review and you believe you are weak and this slows down your productivity. Too much self respect and you write code that is unmaintainable, which in most situations, is really bad. But there is a middle path where you have self respect and know things aren’t perfect and that’s okay. Logically, this makes sense, but emotionally, it is very hard to grasp.

So it’s on you to believe in yourself and it’s on your coworkers to keep you honest. But we should just say that. It makes for a stronger work culture and it leads to optimal productivity.

We can think of this like a set of functions:

productivity(number_of_developers) -> average productivity per day

quality(number_of_reviews) -> average lines of code reviewed per day

As productivity increases quality decreases and so quality must increase to compensate. But this lowers productivity and increases code quality. So how do we counter act this negative externality? I believe the answer is simple, don’t slow down; by reminding yourself you are still intelligent. Of course an over abundance of confidence is very bad and dangerous, but some is good. And worthy of having and further more, it’s good for your career.

Another possible way this could happen:

There is not a culture of philosophical debate in code review and I believe there should be. It makes the work slower, but also allows something else, it allows for the reviewer and the reviewed to be on equal footing, instead of the reviewer having the power. I believe this is at the heart of the bias downward in programming at present. This is why soft skills are so important at the higher levels of software engineering instead of just writing good code. But folks don’t seem to get that.

Even extremely good reviewers still don’t act as interlocutors with those reviewed and thus you are pressed to go back off into the wilderness not understanding the critique. In some ways, this is the reason for the speed of technology, we have redesigned communication and implanted a firm hierarchical structure where the most senior propagate their notions to the less senior. And also, the best ideas do not win. The popular ideas do.

So at the end of the day, I hope this is helpful to someone else who is just starting out there career. Believe in yourself, it’s important. Trust that you got to where you are because you worked for it. Maybe it doesn’t seem that way now, but just look back at all the school, all the time spent learning and really consider, was that effort? Was that work? And if you still feel like it was too easy, maybe you aren’t doing what you love, because when you love something, it’s hard, but you do it anyway.

Eric Schles

Written by

Aspiring entrepreneur with a need to fight slavery, mung data, and live deeply.