By Lekha Surasani

I just completed my first full year as a software engineer and it absolutely flew by.

Along the way, I learned a lot and I wanted to take some time to reflect on it and share what I've learned.

Mentorship

For a while, I downplayed the importance of mentorship in career growth. It takes a long time to find a good mentor, and quite frankly, I still haven't taken the time to find one.

Instead, I opted to learn as much as I could from senior engineers on my team. I was luckily comfortable enough with them to even ask career-related questions. Some examples of questions or advice I frequently asked for included:

What are some good resources to learn x?
What are some things you look for in code reviews?
What are some things you wished you knew at the beginning of your career?
What was your salary at x years of experience?

Be your own advocate

In my experience, when you start a new job as a junior developer, your coworkers will underestimate you at every turn. I've gotten work assigned that's unfortunately simple, uninteresting, and too easy.

This was really frustrating because I felt myself growing bored at my job because I was doing things that weren't appropriately challenging. And, I'm guilty of letting this go on for too long (2-2.5 months).

It took a lot of internal pep talks, but I finally spoke up about it during a sprint planning meeting.

In hindsight, I didn't say much – I said I wanted more complex things to do. Then, I continued actively trying to take on tasks that I thought would be more appropriate, rather than trusting my coworkers to know what was best for me.

Learn how to ask for help

I will admit, I'm still working on this one. I used to ask for help pretty readily early on, but as time passed, I got increasingly self-conscious about it. I was worried that I wasn't showing a better understanding of the code base over time. I was worried that my coworkers might think that I wasn't learning fast enough or that I just wasn't good at coding.

Getting over that insecurity and general imposter syndrome has been difficult. I can't say I've truly gotten over it, but I've taken some steps to mitigate the feeling, including:

Writing down the question that I had or what I was having difficulty with. This showed me that over time, my questions were generally getting "smarter" and that I was asking about more complex things.
Teaching others what I found. If another engineer had a question that I could answer, I'd offer up my help even if I wasn't certain I was right. As you can imagine, my responses were littered with "I think", "Someone please correct me if I'm wrong", "maybe", "possibly", and "it could be"'s. Despite my fears about doing this, I tried my best to remember that it would be better for me in the long run. I could share what I had learned with others while getting feedback of my understanding from other engineers.
Talking about what I was feeling. Another junior engineer started at the same time I did, so I found that talking to her about my insecurities was really helpful. She was able to share how she was struggling as well, and it made me feel like I wasn't alone, or falling behind.

Another reason I stopped asking for help was that often times, I got too much help. I would go to a senior engineer with what I thought was one simple question, and I would leave with all of the interesting parts of the task completed for me. I've been working on trying to ask more specific questions, and speaking up when I think I've got what I wanted, so the help I receive stops right there.

You really don't have to be an expert – really.

"You don't have to be an expert". I heard this so many times while I was considering speaking at local meetups and conferences, and when I started trying to write technical articles. I didn't believe it for a long time – surely that's just what people are saying while they're already really good at said thing.

But one week, work had me diving into a very specific problem – we were upgrading react-router from v3 to v4. This upgrade required a lot of research as some key libraries were deprecated, and there were a ton of breaking changes.

I ended up learning so much about this one specific library. Over the course of many days, I had read so much documentation, github issues, and guides. I took all of the information I found and consolidated it since I hadn't found any one guide that would help explain what was going on in depth.

So, I wrote one myself. It didn't get too much attention, of course. More importantly, I was relieved no one came after me with pitchforks.

Then, I thought about how many "intro to x" articles I read when I first started to learn a new language or framework. They were pretty basic articles, requiring a bit of background knowledge, but overall nothing too technically-controversial.

That's when I decided that React Hooks was going to be the topic of my next article. I wasn't an expert on React Hooks by any measure. It had literally just come out and I'd only used it for some personal projects, but I'd written an article about it. So, really, you don't need to be an expert.

Take advantage of one-on-ones with your manager

And if you don't do them currently, ask for them. I have mine once every two weeks. For me, I found these one-on-ones were a great opportunity for me to reflect on my work, ask questions about things I was confused about, and give general feedback about things that were working well and things that weren't.

Some specific questions and feedback included:

How does this piece of the product work?
Do you see a consistent theme of things in my PRs that could be improved?
I'm enjoyed working on x, but I want to continue exploring other things, so do you think I could start getting work related to y?

Because of these dialogues, I was able to get different kinds of tasks that I was more interested in, learn a lot more about the code base, and generally make parts of my job easier.

Each manager is different, though – so you may not be comfortable with asking the kinds of questions I've suggested, but at the very least, hopefully you can get some useful feedback on your work.

Document

When you're early in your career especially, it's important to document what you're doing on a daily basis. It helps you see your growth, understand your work better, and overall, will help you reflect and understand what you've been working on. As a bonus, you'll be able to come up with points on your resume way easier!

I'm admittedly pretty bad at this. I jot things down in a notebook every week or so, and when I do, I only really take notes of the more complicated parts of our product. Ideally, you'd want to jot down what you accomplished that day and take notes on the code base and general "business logic" more often.

I don't think this is something that's talked/written about enough, but one of the people I follow on twitter, Cecelia Martinez, recently asked her Twitter followers about tools they use to document things, so definitely check it out if that's something you're interested in.

Engage in the community at large

The tech industry is problematic in many ways, but as a woman in tech, it helped me to follow others who had experienced similar things to me. Tracy Lee (CEO of This Dot Labs) has an excellent list of women in tech to follow.

I also joined my city's women who code chapter and I go to a few local meetups. As someone who gets very nervous meeting new people, I found it was a great way to network in a welcoming and friendly environment.

Find non-coding hobbies

When I first started working, I felt a lot of pressure to keep up with the newest tech and to continue learning new things. But, I burnt out quickly because that was all I did.

I took a few steps back and decided to explore doing things I enjoy that weren't coding-related. I starting learning how to play the guitar and how to speak Hindi, I joined a book club, and I started going to the gym more.

All in all, I've learned a lot, and hopefully you've taken away some lessons from my experiences. I'm excited for what this next year holds for me!

What I've Learned in My First Year as a Software Engineer