DEV Community

Tatiana
Tatiana

Posted on

5 Things I've Learned 6 Months into my First Software Engineering Role

It has officially been six months since I started at my current organization. Every day I'm still in a bit of disbelief that I was given a dream offer from this amazing company. Sometimes it doesn't even feel like work, and I'm lucky to be in a role where I have an incredibly supportive team with tons of mentorship, an interesting stack that pushes me daily, and lots of learning opportunities.

Reflecting on the last 6 months, here are some things I have learned:

#1. It's okay to not know everything.

I did recently write a blog about this very thing, but I think one of the most surprising things I realized very early on in my role is that we truly all are in a state of constant learning. I was put onto a team that was sold to me as a team that "skews pretty senior", and as a junior from a self-taught background, I was highly intimidated. I didn't want to be the person on the team lacking knowledge in, well... everything. However, I learned pretty quickly through pair programming and team meetings that these senior devs on my team who had worked at these amazing companies and had many years of experience under their belt had the humility to admit when they didn't know something. And these admissions are frequent! It was humbling and exciting to be able to learn alongside my teammates and even learn how they approach learning something new after years of honing their craft. It was also exciting to be able to drop a few new pieces of knowledge to folks more senior than me as well! I have found the relationship to be oftentimes symbiotic, and the fears I had about not knowing enough to keep up with a nearly all senior team were mostly unfounded.

#2. It's okay to not ramp up at the speed of light.

My organization has an onboarding roadmap that takes about 3 months to complete, as an estimate. This was a relief because I was completely overwhelmed by the sheer scale of what I would be working on compared to my prior work in open source and personal projects. I had no idea how I was going to meet expectations. Ultimately though, it worked out. While all of the feedback I received indicated that I blew that schedule out of the water and ramped up much more quickly than expected, the fact that the roadmap was slated over the course of three months did reinforce that I was totally able to take my time, rather than throwing me to the sharks with unreasonable expectations for immediate productivity.

#3. Get comfortable being uncomfortable.

A new role means a new stack, new services, and a whole lot of areas of focus. I was highly uncomfortable (and still am) with a ton of the services and tools I am using. Ultimately I approach it with a growth mindset because it's not a deficiency, it's an opportunity. Circle back to point #1 above- these moments of discomfort are what makes one grow. I found that being in a near constant state of discomfort has helped me grow exponentially in my technical sophistication and understanding.

#4. The Necessity of Understanding Architecture (When It's Time)

This is something that was completely unknown to me prior to gaining a SWE role. And frankly, studying this wouldn't have been all too helpful given the context vastly differs between working on individual personal projects and large scale systems that serve thousands of customers. A lot of what I'm learning and the concerns they address wouldn't necessarily be relevant to the small scale items I was working on prior to getting my job, so learning them now with immediately relevant services in real time has been super helpful to my understanding.

I'm currently diving head-first into Kafka and event-driven systems, and it's a lot to wrap my head around. However by listening in on working groups, reading implementation specs, and taking the time to read documentation thoroughly, I see the value in carefully crafting a system at scale. Do I fully understand the consequences of particular decisions? No, but I am now cognizant of the importance of being aware of the impact my code can have not just for a feature or bug, but the application at large, and that I have to "zoom out" to truly see why.

#5. The Value Of Rest

I am a high achiever that is constantly looking for the next step. The next promotion, the next project, the next step in my professional development and personal skills. "I got the job! Great. What's next? What can I do?"

It's not in my nature to be "okay" with being "okay"- I care a lot about my craft and how I can be helpful whether it's at work, in my open-source endeavors, or personally. This gives me a bit of a workhorse ethic when it comes to programming. I spend a lot of time after hours and on weekends trying to up-skill or do something related to my personal and professional improvement. However, I recently have come to a reality check (meaning, my body rebelled and forced me to slow down). I cannot work "pedal to the metal", "foot on the gas" 24/7. I have to rest, or I cannot be my very best, and I have absolutely been feeling it for the past few weeks. I love being the best, but it's not realistic to be the best all the time, effort and energy naturally ebbs and flows, and I have to accept that in a mentally taxing field, I must rest. With that, I have implemented a tentative rule to not code after hours, only on weekends.

The Next Six Months

Now that I'm largely settled in at my organization, I'm looking to thoughtfully balance continuing to exceed expectations while honoring myself with rest and proper pacing. I hope to take this opportunity to build an entirely new service to gain an area of expertise within my organization and mirror some of the more senior individuals that I work with who also have a particular domain that they know intimately. Another major focus of mine is increasing my knowledge of TypeScript and ensuring I write extensible, reusable code. Now that I'm working on greenfield services, I'm hoping to fully get on board with best practices and existing patterns across our codebase and I'm taking each code review to heart without taking it personally because I know my team wants me to succeed.

The first six months have been a trip and I am so grateful to be at this incredibly supportive organization, but now it's go time.

Discussion (2)

Collapse
aamnahakram profile image
Aamnah Akram

Hey, thanks for writing this. I'm another self-taught developer making a point to rest these days because of burn out because i like giving everything my very best. Learning the value of rest and being okay with 'good enough' is some sort of a milestone i guess..

Collapse
tatianacodes profile image
Tatiana Author

Ha, I recently read that trying to be your "best" all the time means it's not really your best, it's just average (for you). Conserving your energy and sanity pays dividends because it's simply impossible to always be best, constantly.