Impostors syndrome: that perennial juggling act between vocational ambition and the sneaking suspicion that you’ll arrive at work on a Wednesday only to find your desk sold for parts, the room darkened, and a semicircle of coworkers with flashlights under their chins, serving you with a notarized document that reads “the jig is up”.
I have always struggled with this feeling. I can remember it while learning my multiplication tables back in 1999: “why am I even allowed to be awake during naptime? Let alone carry the burden of figuring out what 12x11 is!”
The feeling particularly crops up when I am venturing into practical STEM subjects, i.e. outside my congenital comfort zone of language-arts. But this monkey has been on my back a long time, and at a certain point, I realized there was just no shaking it off. I felt that my only option was to (masochistically?) mold my career around impostor-dom. To Lean In— the opposite of what Sheryl Sandberg was trying to communicate with that aphorism.
To make a long intro short, this is why I am a content creator/writer in tech. I have not (yet) been to code school. I am not AWS certified like others on my team, and I can’t design a unit test. But I can ask questions! Lots of them. And I can usually find a storyline in the midst of a frenetic engineering brainstorm. Of course, I need to eventually grasp key concepts of what we do, what motivates users and customers, and where the industry might be headed.
But I see my primary value as someone who represents the novice or, perhaps, the person who shows up to an engineering meeting with a raging case of impostor's syndrome. That perspective becomes important in a room full of smart and adroit software engineers.
However, the need does arise for me to my own hand at the tools my coworkers know like the back of their hand. Git is a great example of this. I know the context and purpose of Git and understand its fundamental value to developers, but until recently, I had never actually tried to deploy any code using it. It became clear recently that there were one too many layers between me and getting our blogs online.
Did this set off my internal imposter alarm bells (“…Will everyone finally realize that I’m a black sheep? And not in the good way?!”)? Yes, but I also knew that attempting to take on some of our blog-related coding would be met with encouragement.
{An aside: I've found the serverless community to be an incredibly supportive one. Let’s put it this way: I’ve never felt compelled to write one of those gushing LinkedIn status updates before now (and I’ve written FIVE of them about my current workplace, which operates in the serverless realm). Everything about working here makes me feel like a person, not a cog. #notacog.}
If your background is anything like mine and you work in an environment with as many tech wunderkinder as I do, you’ll agree that Git appears to be very daunting. With this article, I want to open up my experience of what it felt like to learn it in non-technical speak. This is for those who are equally frustrated with the experience of Googling what you think will be a basic Git term, only to find a hellscape of serpentine threads that really bring out the impostor in you (cue Law & Order SVU clunky/scary sound). I don’t have time for that and neither should you.
First Encounter
Two of my wonderful colleagues on our engineering team generously offered to walk me through the basics of Git and GitHub when I first started my copywriting/editing job. It was kind of a brown-bagging session and was very relaxed and high level which was perfect out of the gate. I didn’t need to follow along on Visual Studio Code, although they did recommend I download it that day. Check! Am I Git-ing it yet?
We covered basic concepts like push, pull, commit, and merge, which I’d boldly been peppering into my tech conversations without any personal context. I wrote their meanings down but that somehow didn’t tattoo it into my brain. The day was a win, though, and super helpful as a primer.
Flash-forward a few months wherein other copy projects took precedence over everything that had shared with me. Naturally, I’d forgotten the bulk of what I learned and to make matters worse, there was actually a need for me to learn it in order to save our VP of Engineering from wasting his talents dealing with getting blogs online.
Luckily, one of my colleagues was willing to do a working session that went a bit deeper than our initial Git conversation. When we made a date, I immediately imagined my face superimposed over Owen Wilson’s in Zoolander when he’s breaking that old monitor because “the files are IN the computer!” How silly was I about to look?
Training Day
I was pretty excited to get 1-1 time with an engineer to put all of this git stuff into context. Dreams of updating my Linkedin profile skill section danced in the air. I was about to get all Eliot Alderson up in here. Look out, world! Or should I say: hello, world!
We sat down, connected my computer to AirPlay and gulp I opened Visual Studio Code and the Terminal. Dang it. There’s that nagging feeling of exposure and silliness. Our first task was essentially to copy the source code for our company website website (its “code repository” if you want to seem fancy or just “repo” if you want to seem extremely cool and smart) onto my laptop.
So. Many. Commands. Keep in mind, pretty much ALL of my previous work was being done in Google Cloud so I had never had the need to so much as open up the terminal before. We were truly starting from scratch on my machine. As many of you reading this will know, this process only needs to be done once and then you’re good so one 15 minute session doing this and you never have to do it again. But did I know this? Of course not. Tabula Rasa, party of one.
On minute 10, I gently asked the equivalent of “how do you get so much work done if you need to do this process every time just to open the right folder?” and my coworker kindly explained that, no, this was not some kind of marshmallow test of my patience. We were just laying the groundwork and I didn’t have to take furious notes.
Once that process was finished, she guided me through some basics and used a recent blog we published as a markdown template. Markdown, while pretty straightforward once you do some research, was very foreign to me as a writer. Why exactly do we need to put prose in between underscores and hashtags to format it when we could just type it directly into a word processor? That was the kind of rudimentary question on my tongue.
But after a few more minutes of guided instruction, my colleague had helped me convert the blog into markdown, load into VSC, add images, and commit my changes to GitHub. I was thrilled to have played some kind of small role in getting our blog ready for review, but I also felt a bit like the final runner in a relay race: we got to the finish line, but I had very little to do with it.
The Tunnel of Why
Once my ridiculously helpful and informative meeting with Anna was over, I decided to try to replicate the process on my own and use the
bundle exec jekyll serve -o
command to do a live preview and see whether or not I was getting it right. This made my mistakes evident: all those images I’d carefully placed were sad “broken image icons” and my text styling wasn’t rendering at all. Seeing the problems before someone else had to point them out was a good thing, but it worked me into such a lather that by lunch, I was spread thinner than a moth in a mitten. Or in non-hokey speak: information overload.
This feeling really brought me back to algebra in 6th grade, in particular, something my teacher used to say to me anytime I had a difficult, foreign problem in front of me. My instinct even then was to distract from my anxiety by asking a million granular questions of my teacher as a way to take the onus off of me. She called this “The Tunnel of Why”. Basically, she used that phrase to caution me against entering a rabbit hole of “why this, why that” about the smallest facet of a problem when you are in the height of frustration. Instead, accept that PEMDAS is the order of operations for the sake of getting through it.
Once you’ve achieved the high of getting the correct answer, you can question how you got there. Repeat this until you have a solid foundation of confidence. Essentially, don’t enter The Tunnel of Whys until you have a flashlight.
Since making this connection, I have found the same to be true of learning Git: get the basics from an informed teammate, try to replicate it the exact same way, then wax philosophical once the task is complete and you have time to pick it apart and reverse-engineer.
I think that software engineers have the knowledge of development to pick apart errors and mistakes while continuing to move the task along, but I have a feeling that doing this will slow down and frustrate the rest of us trying to learn Git. My advice is to ask your whys, but not all at once.
Another hero to the rescue
I sit next to our Community Developer, which has all kinds of benefits: she knows a LOT about a lot so if you need carpentry advice, the perfect gif, a metaphor for serverless that somehow relates to the French Revolution, etc. she’s good to have nearby. She also has an innate sense of when I need outside counsel to solve a problem. In fact, she’s probably even better at recognizing it than I am myself. In short, she’s full of good qualities.
So when I came into work the day after “Git Training Day” with a big chip on my shoulder about how much I’d forgotten overnight, she came straight to the rescue and set up a 1:1 with me to basically experiment with different commands, resources, and exercises to tighten my git-grasp. What’s more, she was incredibly encouraging in a way that didn’t feel hollow or simply in the interest of moving along to the next task.
She showed me all kinds of hacks and tricks to simplify my understanding of how to ship our blog and use GitHub, but instead of diving into those things today, I want to share something she explained that is super applicable to anyone suffering from impostor’s syndrome while learning a new technical task:
She told me to think about a pianist. If you were to plop them down in front of a piano on their first birthday, you wouldn’t ridicule them for not knowing how to play Chopin’s Étude Op. 10 No. 4. You wouldn’t even ridicule them for not knowing how to play Hot Cross Buns. You’d actually celebrate that they were brave enough to even approach a huge instrument in the first place. Then, you’d smile (ok, while secretly wincing) when they smashed at the keys even if it sounded like a cuckoo clock in a washing machine. When they played something comprehensible some time later, you’d applaud.
Most critically: even after someone has patiently shown you how to play Hot Cross Buns, we shouldn’t be surprised that we don’t learn it perfectly after just one try. Learning Git and even markdown is the very same and we forget this because we’re adults who know how to read and write; We believe we should have an innate sense of how to accomplish these tasks simply because we know how to use a keyboard, but this just isn’t realistic. These things are hard when you are starting out. You have to give yourself that.
So, yes. With the help of my awesome cohort, I've posted countless blogs to our website using Git on my own (if my 6th-grade algebra class could see me now)! Over the past year, I’ve figured out how to get prose into markdown, deal with VSC, conduct a live preview of my work, commit/push it to GitHub, and repeat the process when I get feedback.
This is small potatoes when it comes to my team, all of whom are working on solving the world’s toughest serverless problems, but it still feels significant and valuable to me. I’m really excited to keep learning more and share my progress in the future!
A version of this post was originally published on the Stackery blog
Top comments (1)
Entertaining read!