We've all read those op-eds in the Smarter Living section of NYT about impostors syndrome. After all, they have been getting more and more traction as a new generation enters the associate-level in their career. Impostors syndrome: that perennial juggling act between vocational ambition and that 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'm a tech copywriter, specifically at Stackery. 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 our customers and team, 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 one of our meetups with a raging case of impostors 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 a good way?!")? Yes, but I also knew that attempting to take on some of the blog-related coding would be met with encouragement.

{An aside: Stackery is just about as supportive a workplace as you can find. 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 Stackery). Everything about working here makes me feel like a person, not a cog. #notacog.}

But 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 series, 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 conveniently both named Anna and Anna: The Patron Saints of Git (yes that is their full title and you will address them as such) generously offered to walk me through the basics of Git and GitHub when I first started. 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 A^2 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.

I can't remember if I or Anna Spysz first suggested I revisit Git, but either way, we decided it was a good idea. 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 Anna 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 Stackery's 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 Anna 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, Anna 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, Anna 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.

*Most "Tunnels of Why" aren't this scenic. Trust.*

Toby to the rescue

I sit next to our Community Developer, Toby, 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 birthdayday, 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, the blog you're reading was brought to you by me (if my 6th-grade algebra class could see me now)! Over the past few weeks, 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 a future installment of this series!

Stay tuned for part II: how to optimize the GitHub workflow as a content marketer.

Are you stuck in a "Tunnel of Why" about serverless or Stackery? We have a solution for that! Join my team on Wednesdays at 10 AM PDT to ask our engineers and guest hosts your questions or share what you're working on. I promise you that they have all kinds of helpful answers about all kinds of cloudside development problems. Just look at what they taught me to do!

Register for the next livestream here