I am totally faking it.
I’m not a “real” coder
The tl;dr of my path in life is that I am not a “real” coder. I graduated college in 2008 with a degree in business focusing on econ and finance and went straight into banking as a treasury analyst. I was a bit restless and wanted to get an advance degree, eventually making my way through the industry to the Board of the Federal Reserve Bank, who makes economic policy decisions for the US.
So I decided to set my sights for a Financial Engineering masters degree at UC Berkeley. But! Applicants had to prove they knew how to code in C, which I didn’t. Therefore the most suitable solution I thought was to take an intro to Computer Science course for credit. In the fall of 2011, I enrolled in the CS50 course at Harvard, thinking that it’s only been a few years since I graduated college, and therefore knew how to study.
I failed. I failed both the mid terms. And not like “a B isn’t an A” sort of fail. But “here’s a D, you should be thankful for the grading curve.”
I could not understand concepts that are core to programming, like memory allocation, pointers, and dereferencing. I knew that sorting algorithms existed, but how to implement a simple Insertion Sort in C? Instant deer-in-the-headlights.
So for the course’s final project, I decided to make a website built using Python. I chose Python because I saw my boyfriend writing it and thought “woah, I can actually read it, understand it!” It was a little app - with really awful and repetitive code - that calculated a user’s personalized inflation rate over 10 years. For example, based on income and purchase habits, a retiree experiences inflation different than one who is in a marriage with 3 kids, or a college kid.
So because I made a working site, and learned Python & Django for it, I finished the course in December 2011 with an A-. Not sure how that computes with two failed mid-terms, but I’ll take it.
Unconventionally educating myself at the expense of others
I was hooked though - I want to code more. Screw finance. Screw getting a master’s degree. 3am never looked better when debugging my stupid little website in Python. Rather than paying another $2,000 for a Harvard course that didn’t even teach Python, I looked to the local community.
So in January of 2012, I started a women-only, Python-centric study group through the Women Who Code (WWC) Meetup - graciously hosted by Dropbox. I did it through WWC because having attended previous events, it was a super supportive environment and I wanted to plug into that.
I created my own sort of “course”; it was an 8-week series that I made a curriculum for, where each week would be a mini project for a few hours on Wednesday evenings. I would digest the project, teach myself the week before, then “present” and work through it during the study group.
Side note: My boyfriend and I had recently moved down to the Bay Area for his job. It was wicked difficult to find employment in banking at that time (and I’m sure it still is), so suffice it to say I was unemployed with plenty of time on my hands to learn.
I will have you know that I completely fumbled through that whole series. The folks at Dropbox gave some solicited feedback that perhaps a more experienced Pythonista would have been better. But I found the study group to be very successful. Week over week, the group was at max attendance with about 40 women. Sure, they may have come for the free dinner provided by our hosts, who can blame them. But they stayed for some reason.
Feedback from attendees that I received was great. Rather than the environment setup with an experienced lecturer, being “here, I have the knowledge, and you are here to learn what I want you to learn.” It was more of a “let’s fumble through this together,” eliminating the ego factor along with the competition that can happen in classic classrooms.
Conveniently, PyCon 2012 was scheduled towards the end of the study group series right in Santa Clara. I was able to get a few free tickets for the March conference along with sharing a ZipCar for a few study group’ers.
NB: PyCon in 2012 was my very first conference ever, and my experience there changed me for the better. More on that in a bit.
But at PyCon, folks that originally started PyLadies (originally started in Los Angeles in late 2011) approached me as they were aware of the study group I was doing. They suggested I start a San Francisco chapter of PyLadies.
Naturally, my first thought was “wtf why isn’t it in SF already?”, followed by “F*CK YEA LET’S DO IT”. So April of 2012 was the official launch of PyLadies in San Francisco. We are now at 1800+ members which is the largest chapter of PyLadies out of over 50. Since the the start of the SF PyLadies, I have regularly hosted events including workshops like before, as well as speaker events for inspiration, and general drop-by study groups for women interested in getting their feet wet with Python.
How I fake it
For some reason, women keep coming back to these events hosted through PyLadies. So I must be doing something right. So how exactly am I “faking” it? Essentially, my process is:
Step 1: Break everything.
First step - break everything. Mind you, breaking shit isn’t intentional, but a natural habit of mine. I try and follow some tutorial online or instructions given to me, and lo & behold, I accidentally delete my project directory instead.
Step 2: Ask for help.
So then I ask for help, naturally. I have my boyfriend, who is a very experienced software engineer. But I also had Twitter, which I preferred.
As you can imagine, the usual responses I got - though - was “Read the fucking manual,” or “let me Google that for you.” Great, thanks for the helpful advice!
Step 3: Break more shit.
So then I would struggle some more, break everything again but differently. Trying to undo what I broke before, redo it correctly, and breaking something further down the line.
Step 4: Success!
But then something would work! My website could run locally! And I wouldn’t be able to explain why! But I’ll take it!
Step 5: Break it again.
And as soon as the boyfriend would come home, I’d be super excited to show him my success. “ZOMG DOOD LOOK AT WHAT I DID!!11!one!”
And as you can imagine: it would not work. I broke it again. (Learn version control the hard way, huh?)
Step 6: Cry.
As you can imagine, this whole process is aggravating and energy consuming. So frustrating to think you’re following instructions exactly, to only notice you were in the wrong directory, had a typo, or needed to install some header files when it wasn’t in the instructions.
So I’d cry! I’d cry often! And I’ll be frank - I’m not embarrassed to admit I cry.
One of the reasons we cry - beyond tearing up from having a cold, being out in freezing temperatures, or cutting an onion - is from an emotional response. From this built up stress, my eventual, viseral reaction is to cry.
A little science fact actually: Tears that come from emotions have higher levels of stress hormones versus tears from cutting an onion, allergies, etc. They contain ACTH - a hormone that regulates our adrenaline, as well as Enkephalin - one of the body’s natural pain relievers. And crying is actually one of the body’s quickest ways to release that pent-up stress.
Therefore, I do suggest frustrated new coders to allow themselves to cry. Of course, folks may also mitigate stress via exercise, meditation, perhaps a glass of wine or four. But don’t be embarrassed if you want to cry - it’s a biological mechanism we have at our disposal.
Likewise, in my experience, after a good cry, and maybe some time away from my computer, I am of course feeling physically better. And then a big break through happens! Now I don’t know if it’s scientifically provable, but I always seem to have a break through post-cry. Whether I epically redeem myself at work after looking like an idiot, or finally deploying my dumbass little app, I have a win. So I can trust that my need to cry is just the lowest point of the current break-learn-break cycle I’m going through.
Lather. Rinse. Repeat.
I pretty much went through this cycle of breaking stuff, some successes, got some help, or combed through documentation, with various-sized successes along the way.
To help illustrate - I made this super awesome graph of my process in faking it:
I start off mediocre and fumbling, I break stuff, then have minor success. I break more stuff and maybe have a bigger fall being so frustrated, then comes a bigger win. That’s how it feels to me.
Now how it actually looks like to everyone else is more like this:
Where I make progress by breaking and learning, plateau from frustration, and continue on upwards. I may relearn something from the past week or month, but I’m definitely more knowledgable than 3 months ago, 6 months, or a year.
A saying that I find illustrates this comparison very well is to not compare your own “Behind the Scenes” takes to someone else’s “highlight reel.” People will only see your “highlights reel.” It may seem like I am struggling on a constant level, but what folks see is upward progression.
Similarly, I saw this image over two years ago and it has been my internal mantra ever since:
How I’ve “made” it
I explained how I am not a “real” coder, and how I’ve been faking it. But how exactly have I made it?
Earlier I mentioned going to my first conference - PyCon 2012. That inspired me so much that I started proposing talks. It just looked like so much fun!
My process in proposing talks was pretty much throwing spaghetti at a wall to see what sticks. Of the Python/open-source conferences I first applied to in mid-2012, all of my talks were accepted. Diversity was just becoming very important within the Python community, so I was essentially speaking about how my learning how to code using the community - by doing study groups and workshops - and how that has been having an impact to effect diversity.
A new chapeau
Coincidently, my second talk ever caught the eye of a Red Hat recruiter, giving me my first official software engineer position.
While working at Red Hat, I:
- Broke things;
- Wrote up HOWTOs how not to break things;
- Moved on to break the next thing.
And so as I was continuing my break-learn-break-cry-break cycle, the tide started to shift. Rather than submitting talks, I would get invited to speak. I started getting invited to host PyLadies workshops abroad, helping new chapters start up. I was voted by the Python community to the board of the Python Software Foundation. And then a member of the Django Software Foundation. I started regularly being solicited from recruiters; first from brand new start up companies that failed faster than the recruiter could hit send, and then eventually more established ones.
And so after a year at Red Hat, I left to join Spotify for a better opportunity.
I’m not the only faker
As I looked at my progress in the context of my faking it and seemingly making it, I could tell that others had to be sharing my secret. I’m not the only faker. Everyone else is a fraud, too.
You may or may not be familiar with the 10,000 hour rule. It’s defined by Malcolm Gladwell’s Outliers book, where the key to success in any field is a matter of practicing a specific task for a total of around 10,000 hours.
Now, Americans average about a 2,000-hrs a year at work having the standard 40-hour work week. So that 10,000 hour rule would at minimum be accomplished in 5 years. But I’m sure not 100% of someone’s day is focused on a particular skill, like coding. Everyone has meetings, emails, water cooler chats, etc. So perhaps it’s more like 7-10 years to achieve that.
Going by that fact alone, my peers who are “classically trained”, i.e. have a degree in Computer Science (which can truly only be at most 2 years of experience in coding), they can not be experts by that 10,000-hour rule.
More so, let’s add in the fact that this industry is always changes, with the new “in” technologies and frameworks coming and going as fast as we refresh our browser page - how can we become an “expert” when being an expert itself is a moving target!
Another way that I know I’m not the only fraud: job applications & interviews.
One of the effects of impostor syndrome is not applying to jobs, promotions, or other opportunities. Sound familiar?
When I was at the early stages of learning, I wanted to get interview practice to see if I was on track with my progress. I applied for jobs I was barely qualified for. I felt less pressure since I wasn’t really trying to land a job.
But I’d actually get called for interviews! Apparently I was competent enough; perhaps these recruiters were scraping the bottom of the barrel, but at least my fake-coder experience surpassed whatever bar that my impostor syndrome artificially set.
When I did a second round of interview practice about a year later, I certainly got much further, but the impostor feeling was still there. Though yet again, because I’m faking it, and my “faking it” was acceptable for these companies, how could others not be as well?
tl;dr: Continue faking.
Essentially, I’m saying that I don’t have a conventional education for my line of work, nor my experience level matches those of my peers. It’s what makes me feel like a fraud. However, the successes from my break-fix-break learning cycles builds up. It’s evidence that I am - for some crazy reason - “making” it.
But this community can make us feel that we should have read the 2000-page “How to be a software engineer” manual over the weekend - and be ready to implement TLS in like, Assembly code. That’s crap. Ain’t nobody got time for that. The sheer progress I’ve made - becoming an engineer in 1 year - is evidence to me that I’m not alone.
So I’m not writing this to pass on some huge, 24k golden nugget of advice on how to rid yourself of feeling fake. No. Shit, I haven’t figured that out. But it’s along the same lines of “becoming comfortable with making yourself uncomfortable”: become comfortable with being a fraud. Embrace your fraudulent self.
My story here by far pales in comparison to Ms. Lovelace. But it’s my story that barrels through impostor syndrome not to exactly get rid of it, but to celebrate it. It is possible to fake it until you make it.