2016 has been a crazy whirlwind of firsts for me.

I started writing my first lines of code, first in Ruby and then in Javascript. I quit my job for the first time to attend Grace Hopper Academy, NYC’s first all-female coding bootcamp. Now, I’m one month deep in my first software engineering role at Major League Soccer as the first female developer on our team.

It’s been a blur, to say the least. Between setting up my dev environment to learning our system architecture, to meeting all new faces and shipping my first lines of production code, I’ve felt excited, scared, and overwhelmed all at the same time. But, I made it out of the first few weeks alive and finally feel like I’m starting to piece together parts of the puzzle.

If you’re reading this in anticipation of your first engineering job, you’ll probably experience similar emotions too. It’s totally normal and I’m here to tell you that things will get better!

Here‘s what I’ve learned along the way:

1. You will feel like a beginner all over again.

Coming out of a bootcamp, I didn’t realize how steep the learning curve would be transitioning to an enterprise codebase. At Grace Hopper, I was accustomed to writing apps for no more than 10 users per day. Fast-forward to MLS, where our apps receive over a million hits per hour on a big game day. Suddenly, things like caching, performance, and scalability became important and I had absolutely no idea on how to manage them. I felt as if I was back to square one learning how to execute a for-loop.

It’s okay if you don’t have all the answers yet. I’ll let you in on a secret — nobody expects you to! Remember, you weren’t hired for your experience, you were hired for your ability to be curious, learn quickly, and ask thoughtful questions. So, keep doing those things, even if you feel like you’re drowning in information.

Despite your efforts to stay afloat, sometimes feelings of doubt and uncertainty will creep in. Around the halfway point of my second week, it happened to me.

I was pairing with our lead developer on a React component when I allowed the nagging voice inside my head to get the best of me — how on Earth did I get hired? It must have been luck because my code is so sloppy. I just got the hang of ES6 and he’s already writing stage 2 ES7?! 😳

That’s called imposter syndrome and it’s for real. Nearly all programmers experience it, from the most experienced to those just starting out.

Instead of dwelling on what you don’t know, get excited about all the cool things you’re being exposed to! Jot down any unfamiliar frameworks & tools and research them later. Since I’ve started working at MLS, I’ve learned how to cut down on boilerplate unit testing and type-related errors with Flow. I’ve seen the power of Service Workers in action and how they allow caching in the background so your app can run offline. I’ve even started diving into Kubernetes and how it simplifies managing our applications in production.

Be a sponge. Absorb all of the knowledge you can in your first few weeks, especially when pairing with more advanced teammates, but don’t let it consume you.

2. It’s okay to break things.

It was around the end of week two that I started to work on my first feature ticket alone. I tried to make sense of what was going on as best I could, submitted a PR, and waited for the build to complete.

All of a sudden, the notifications came pouring into Slack alerting our entire team: Build failed! I wanted to crawl under my desk and hide! 🙈

Just because your code fails a build doesn’t mean that you are a failure. So, get out from underneath your desk, dust yourself off, and ask for help.

Our tech lead reassured me that failing a build isn’t a bad thing at all — the reason we have builds is to ensure there are checks & balances in how we deploy. Having them allows you to experiment with changes and move quickly while guaranteeing you don’t ship broken code.

Honestly, I still get a little paranoid every time I merge into master, but those feelings are slowly subsiding as I learn to trust the system.

As software developers, we’re constantly testing out solutions. And yes, we will inevitably break things from time to time. You can always restart the pod, roll back the build, or git rebase. Life goes on.

3. Contribute in other ways beyond writing code.

When you’re first starting out as a developer, you can often add more value to your team writing English than code. That sounds counter-intuitive, but hear me out.

Chances are, if you’re like me, you’re not a rockstar developer yet. You’re still very much in the learning phase for most tasks, rather than the doing phase. Adding a property to Redis or working with Docker containers isn’t second nature to you just yet and you have to follow step by step instructions on how to accomplish them. That’s actually a good thing, especially when it comes to writing clear documentation.

Although our team had some onboarding how-tos, they were written from the perspective of someone who’s already been programming for years. As the first person on our team hired at a junior level, I have a unique opportunity to assist with simplifying our manuals.

Take really detailed notes! My desktop is cluttered with virtual sticky notes covering everything from StatsD monitoring to JIRA/Github workflow. Not only has writing the sticky notes helped me cement everything I’m learning, it has also helped my team by providing easy to follow instructions for the next hire. We’ve already transformed two of my sticky notes into official guides on our Confluence wiki and plan on adding more in the weeks to come.

Don’t stop at writing documentation. Including thoughtful comments on your PRs and testing notes is a great way to demonstrate your knowledge to your team. Share with the programming community what you’re learning by tweeting! And please, write a Medium post reflecting on your experience — there aren’t enough articles out there offering a new developer’s perspective, which is what inspired me to write this post in the first place.