Last month, I celebrated my one-year anniversary as a software engineer! I still remember when this career was an impossible dream. Today, I consider myself to be a highly capable engineer, and have grown so much over the past year.
In celebration of my one-year anniversary, here is a list of “cheat codes” I’ve learned that accelerated my growth as a junior software engineer.
Shipping code fast is the #1 way you can add value to your team. As Gergely Orosz says in the book, The Software Engineer’s Guidebook, “If you’re not seen as someone who ‘gets things done,’ nothing else will matter.”
When it comes to proving your “worth” as a junior engineer, the amount of code you produce and the speed at which you produce it matters more than anything else. This is important to remember, as there is often glue work that needs to be done to support the team’s health. But, as a junior engineer, shipping code should be your top priority.
When I was on my company's experimentation team, I noticed there were a lot of missing runbooks that could help our team solve infra issues much quicker. And while I was passionate about creating these runbooks, this work didn’t excite leadership. So, the work I put in was eventually scrapped. This means I wasted effort on work that ultimately would not get me considered for a promotion or bonus.
If you’re a junior engineer, your focus should be shipping code above all else. Because when it comes to deciding which juniors get the big bonuses and promotions, leadership will first look at your code.
Some additional tips and resources:
Sometimes you’ll get stuck. Maybe you’re confused on how to debug a piece of code. Maybe you can’t seem to get anyone to review your PR. Or maybe the senior engineers who assigned you a project can’t agree on the requirements.
There are many instances where it will be difficult to complete your work. Regardless of the reason why, you must find a way to move forward. Because ultimately, you are the owner of the task and you bear the responsibility of its success. Like my favorite radical accountability quote says, “It’s not your fault, but it is your responsibility.” So, find a way to make progress.
Getting stuck is inevitable, but you don’t have to stay stuck. Err on the side of action and be ruthless in following up until you get the support you need. Don’t worry about bothering people or being annoying. It’s the responsibility of your manager and team to support you. And, it’s far better to be an annoying person that gets things done than an overly considerate person with zero work to show.
Reviewing PRs is great for two reasons. First, it helps your teammates get their work done, which can earn you karma points for later.
Gergely Orosz calls this karma goodwill balance in his book - “When you help others, your goodwill increases. When you ask for favors it can go down… Increase this very important balance by helping others.”
Since PRs typically require 1-2 reviewers, volunteering your time to help teammates get their code shipped is a great way to ensure you have enough karma to get help when you need it.
On top of being good for karma, reviewing PRs can speed up your technical skills. When you do a code review, you are responsible for reviewing every line of new code. And to review that code, you must first understand it. This fact alone has provided an environment to understand my team’s codebase at a deeper level.
Sometimes, during a PR review, I learn how different components of our system works. Other times, I learn about in-house or open source tools that can be useful for my own work later on. And sometimes, I learn new implementation techniques I wouldn’t have thought of on my own. Because I’ve made the commitment to review PRs daily, my technical knowledge has grown and made me more effective as a teammate.
Sometimes, other junior engineers tell me the idea of reviewing PRs is intimidating. “How can I do a PR when I don’t even know anything?” And, trust me, I used to be the number one person asking this question! The truth is, as junior engineers, we have a unique ability to see the codebase with fresh eyes, and this skill is a valuable asset for senior engineers.
Usually, when I’m reviewing a PR, I’m not trying to spot “mistakes” in the code - I’m simply trying to understand the pieces. And when I can’t understand the code, I ask questions. Sometimes these questions have even helped senior engineers see and implement their code differently!
So, don’t be intimidated - we all have value!
Some additional tips and resources:
When someone explains a technical concept, try to get it recorded. This may be easier said than done for in-person workers, but - as a remote worker - this cheat code has been vital for my success.
Often, when senior engineers explain technical ideas, they have the tendency to “brain dump” and speak really fast about complex technical pieces. Even if you ask a bunch of questions or continuously recap to solidify your understanding, there is no guarantee you will remember all the information.
So, record it. (With permission, of course.)
By recording, you can ensure you have a nice little artifact to review whenever you need it. And your senior engineers will appreciate not having to repeat what they already explained 2-3 times.
An important part of getting work done is creating an environment that allows you to do deep work without distraction. Notifications are the antithesis to this.
So, kill your notifications. If you have a Mac OS, this is easy to do with the built-in Focus Mode. For other platforms, you may need to set preferences for each distracting application. But, no matter how long it takes, the work is worth it.
As someone that struggles with anxiety, silencing notifications has not only been great for deep work, but it’s also been essential for my mental health. I still remember the feeling of nearly crying because I kept getting pinged from stressed out users constantly while I mitigated an oncall incident. The stress was almost too much to handle.
So, I don’t allow notifications. I still allow interruptions for meeting reminders, but everything else is silenced. Even if something needs “urgent attention” - unless I’m oncall (and sometimes even when I’m oncall) - people can wait for a response.
Did this blog post resonate with you? Reach out to me on Twitter/X, Bluesky or Mastodon and let’s talk about it!