10 Months as a Software Engineer

Howdy folks 👋🏻

10 months ago, I got my first real job at an American startup working remotely, and that was a significant transition in my life, moving from working on simple learning projects by myself to working with a team of 4, with product management, agile methods and a bunch of new everyday tools, so here's my overview of my first 10 months as an entry level software engineer.

The beginning

After I graduated high school in 2022, I started learning web development on my own with C# and ASP.NET Core, and I was building some simple projects like a todo management app, a clinic management system, and a real-time chat app. Until June 2024, that's when I was hired as a Software Engineer 1, or basically, an entry-level Software Engineer.

For starter, I had to go through an onboarding project to familiarize myself with the tech stack and patterns we use, luckily I was already well experienced with Blazor and Web API so it was fairly easy for me to go through the project. The project was simple as an idea, but it required me to go through and learn some new things that I'd have to use on almost daily basis.

• Clean architecture
• MediatR and CQRS
• Setting up a project in Azure DevOps
• Creating a CI-CD pipeline for building and publishing the application to Azure App Services

And a few more things. I used to join daily scrum meetings and share my updates and progress with the team, showcasing some code snippets and progress on the user interface, while the team shared their progress on features we were integrating or bugs we were knocking out.

Since I already had good experience with a lot of things that the onboarding project is supposed to teach, I was done with it in 10 days, and soon enough I was participating and contributing on the actual codebase with my first contribution being a small bug that involved a tiny change of a line or two in a service project.

Things I learned

When I was working by myself, I thought I'd known everything and that I'm superiorly smart, but the moment I stepped foot into a real job, I felt I was lacking even basic knowledge, some imposter syndrome just kicking in. To me, it was hard to navigate a very large codebase with 30+ projects in a solution, while in my normal projects, the most complex project had 4-5 projects.

After a while, I started learning to read code better and understand where my focus should be when I pick up a new task, or the blast radius.

The blast radius of a code change, be it a new feature, a bug, or refactoring, is the scope of files that are going to be affected by that change. I learned this expression from listening to a podcast named .NET Rocks.

When I pick up a new task, first thing I got myself to do, is figure out what are the files I was going to touch, how does the flow go, like where is this code I'm changing/adding is going to be called from, and what is it going to call, this helped me navigate more quickly, and be able to move around more confidently because it was pin-pointing the area of work for me and I no longer had to bounce between files to know where my next step is.

Don’t seek guidance the moment you get stuck, at the very beginning, many things may not make sense, and understanding the problem at hand could be tricky if you’re not familiar with the codebase, but always give it a few tries before resorting to asking for guidance, because that will help you build a more robust foundation of the code you’re trying to understand since you’re breaking it down piece by piece yourself, and you’re also teaching yourself how to traverse a problem from start to finish. It’s very important to ask for guidance on things that might take you so long to figure out, because you will be using company time and resources if it’s going to take you days to resolve something that could be straightforward for one of your teammates, so it’s always important to balance between when to seek guidance on something, and when to try and wander on your own. But always make sure to give it at least a couple attempts before asking for help.

Another really cliche thing I’ve learned, programming isn’t always writing code, yes I know, all of us have heard that a bazillion times already, that’s because it’s true. Most often than not, you’ll find yourself chasing bugs, debugging old code to see why it’s no longer behaving as it should, or writing tests to verify the new code that was added, does indeed behave as it should. Additionally, you might get into design questions and architecture decisions, so it’s really not always freshly baked code and features you’ll be implementing.

One thing I also highly encourage other developers or generally anyone to do, is to be curious and get involved in things that may not even be your level. We have a pull request policy of at least two required reviewers, and these reviewers are senior-level engineers, even though I’m an optional reviewer, I still go ahead and review PRs, and sometimes I even leave comments for the PR owner to resolve. This not only trains you to get used to doing more senior-like tasks, but also makes you learn from the work of others, identify how your teammates are tackling problems, the solutions they’re using and how their perspective differs from yours on solving a particular problem. And most importantly, someone may forget or not notice some piece of code that’s not properly done, and it might slide to production which could cause bugs that are much harder to surface up later on, so you could also be doing your team a good favor as well if you pick up on.

Last but certainly not least, don’t be afraid to say “I don’t know.” That doesn’t mean you don’t try—it just means you’re honest. During my interview, I was asked a question about microservices and messaging libraries, which I wasn’t familiar with at the time. I felt stuck and couldn’t even begin to form a proper answer, so I simply said, “I don’t know.” To my surprise, I was actually praised for that. The interviewers took the time to explain it to me and said it was refreshing that I didn’t try to make something up. I was able to be honest because I had done well on previous questions. In moments where you genuinely don’t know something, it’s perfectly okay to admit it—sometimes, that honesty creates a great opportunity to learn.

Final thoughts

I wanted to share with this post some of things I’ve learned and experienced in my first 10 months as an entry level software engineer, I hope that might have taught you something or you found something that resonates with you. Feel free to drop your thoughts, the things you agree and disagree with in the comments section down below so others can benefit as well.

Thanks for reading