I had read about Impostor Syndrome before. I recall thinking that it sounded like a silly idea. I never thought I would experience it first hand. This previous year though it seems to have affected me harder than I’d like to admit.
Someone who I consider an essential mentor in my career recently retweeted a link to an article which got me thinking. The article was about fostering a culture of belonging at work. After reading the article, I started to realize that I’ve subconsciously felt this way.
One of the few graphics that accompany the article stood out to me. It was two pie-charts. One for when you feel you belong, and another when you don’t.
The first pie-chart shows when you feel you belong, you spend about 10% of the time worrying, and 90% of the time working. The second pie-chart shows when you feel you don’t belong, you spend 33% of the time working and 66% of the time worrying.
I began thinking of my time at Edmunds, and all my contributions and the realization began to settle in slowly.
You see, the last sprint I had a straightforward story. My task was to convert standard text input to a numeric input so that when users on a mobile phone used our widget, a number pad would display when entering a Year as opposed to the regular QWERTY keyboard.
“Too Easy!” I thought.
By the end of the sprint, I was still tackling the same problem. I had paired with one of my coworkers and found the magic combination.
Hint: it was an input element with two attributes:
<input type="text" "pattern="\d*" />
Adding this to the code base was a lot more complicated than I anticipated. What has been my trouble all along is the extra complexity that exists to our code.
To add a single Input element, I have to dig through 4 levels of scripts. Each level of the script adds another layer of complexity which, to my pea-sized brain is entirely unnecessary.
When I ask about this, I’m told that we’re using design patterns to help make our code more maintainable.
I spoke to a coworker outside of my team about how I felt this was unnecessary complexity, but they felt that maybe we were trying to do things the “React” way without using react (the code I was working in was vanilla js).
Around this time is when the Impostor Syndrome begins to kick in slowly. Everyone seems to agree that this is the “best” way to do things. Everyone in the company does things this way.
I ask for help, and I get a brief walk-through of the code which seems to make sense at a high-level but digging deeper I invariably get lost. Am I an Impostor? I mean Seriously though.
Most people that I’ve found who deal with impostor syndrome seem to be very qualified (see Alicia Liu’s article Overcoming Impostor Syndrome) and it is difficult for me to understand how someone like Alicia, who:
“Started making websites at 15, took programming and web design classes in [her] tech-oriented high school, was accepted by [her] first choice school and majored in Computer Engineering, had great internships at a tech giant, wrote code that was used by millions of people, graduated with distinction, and Co-Founded a software startup.”
- Alicia Liu
That school? The University of Waterloo. The tech giant? Amazon.com.
How could someone like that ever feel like an Impostor?
I could completely understand how I “felt” like an impostor.
I was self-taught. Everything I learned was from checking out old books I found at my local library, eventually upgrading to using StackOverflow and reading documentation until my head hurt and eyes burned. Early on, I used my salesman skills to sell “expertise.” What about me was it that had my customers saying “yes.”
I put in countless hours, blood, sweat, and real tears learning what I needed to get the job done. Often I sacrificed time with friends and family, at times neglected my wife for days at a time and “burned the midnight oil” to make sure I was hitting my project goals, tasks and delivering results on time.
As I transitioned from working with small clients as a freelance contractor to becoming an employee for larger, more established organizations the fruits of my labor began to flourish.
I was leading small teams. I Architected solutions, and often I tackled challenges that others would refuse to do.
In one case we had hired a Senior SQL Developer who knew I was self-taught and made a point of reminding me that he had a “Masters in Computer Science.” He gave his two-weeks notice out of frustration because the deadlines were tight and he couldn’t solve the problem. After he quit, the task circled back to me. I solved it my “dumb” way: My simple brain went the “easy” route. I exported a data dictionary and an Entity-Relationship diagram, found the data I was looking for, wrote a few stored procedures to accomplish the calculations we needed, and in a few days, I had a solution which deployed to production.
Had this just been luck?
I often hear about how how we “write code for humans”… Working at Edmunds, it seems to be completely different.
I am working with smart people.
Most of which have their degrees in computer science or engineering.
In the year I’ve worked at Edmunds, every time we have a new hire they announce the new employee with a list of qualifications. Where they came from (University), what they previously did (Employers) and what awesome hobbies they have.
Every time I hear this I flash back to my introduction where the main thing said about me was “He ran a consultancy, likes Karaoke and plays the Ukulele.” I cringe just thinking about it.
But then again, I remember my 5-hour interview where I met with 10 different people, two at a time and fought my way through whiteboard tests, explained my previous projects, went into detail on how to solve problems I didn’t know, or provided examples of working with stressful conditions (or people) and how I overcame such conditions. I received the job offer, an hour after my interview on the drive home.
Recently I even mentored to a couple of developers, both completely new to the industry and both found jobs (one of them landed his first full-stack developer at $80k a year all based off of my mentoring and guidance). If I can accomplish that – I must be doing something right. Right?
Matter of fact, I even went as far as joining a boot camp two years ago, to make sure I knew what I needed so I wouldn’t just base everything off of my self-taught experience (in hindsight, I knew 80% of what they taught me). A few weeks ago, we discussed Full-Stack developers at work, and a senior coworker of mine brought me up as an example. He said:
- Jason L.
I squealed with glee internally. I felt not only do I belong here, but I have fought my way through and earned it. It wasn’t handed to me. It wasn’t an accident. I’ve proved it throughout my career and confirmed it in my interview.
But then fast-forward to last week, and I can’t add a damn attribute to a damn input element?
What am I missing? In my last three jobs, I was the “Senior Software Engineer,” “Senior Programmer Analyst” and “Senior Tech Lead.” I worked my way up to those positions in every job.
What is it about my current situation that makes me feel like I’ve downgraded myself from “Senior” to “Mid-level.” Am I for the first time working with “real” developers? Do I for the first time realize I am not a “real” developer?
I don’t know.
I wish I did.
This June will be my 17th anniversary of coding professionally. Sometimes it feels like it is my first.
They say the first step to “overcoming impostor feelings is to acknowledge the thoughts and put them in perspective… “
It is reassuring to know that most people experience this. From Seasoned professionals to entry-level developers and everyone in-between. The next step is finding a solution to this problem. If I can “simplify” it the way I “simplify” complex issues, then the answer is right in front of me.
Have you felt like this?