What I Learned in my First Year as a Software Engineer

Photo by Jeremy Bishop on Unsplash

A few weeks ago, I was chatting with some fellow new graduate software engineers (SWE) in my org — answering their questions and giving some general advice. These informal chats forced me to reflect on how I navigated my first year as a SWE. Although the advice I’ve curated below is specific to what I learned within my role, my team, and my company, much of it is applicable to any role, within any team, within any company.

Disclaimer: I’m fortunate enough to work for a company where the culture places a huge emphasis on personal/professional growth, and where my expectations are clearly laid out for me before each review. Some of the strategies below depend on having such systems in place, but that’s not to say the general idea behind them can’t be extended to experiences in other companies.

Your expectations

The expectations for an entry-level software engineer aren’t rocket science. Overall, your expectations boil down to the following: get your work done mostly on time, ask for help when you need it, and challenge yourself as time goes on. You might look around at your peers and feel pressure to start driving projects, or owning features end-to-end right away (I’m lookin’ at you, new grads). Take a step back, and use this time to gain a breadth of knowledge in the systems your team owns. Your responsibilities will pick up as you level up — that’s a given — but never again in your career will this little be expected of you. Take advantage of it! Gaining a breadth of knowledge is helpful in a few different ways:

• Get a hang of what you do and don’t like to work on. When it comes time to grabbing bigger chunks of work, you can make an informed decision.
• Become a confident oncall. You’ll get good at diving into new codebases and confidently making changes.
• Get a hang of your development workflow. How does code get rolled out? What testing processes do you need to be aware of? What teams do you need to loop in for certain changes?

Questions

Use this time to ask questions — there WILL come a point when people will expect you to know your shit, so don’t shy away from bugging people early on. That said, here’s some advice for how to ask questions effectively:

• Spend at least 30 min — 1 hour trying to figure out the answer yourself. Any time beyond that is usually time wasted, unless you find yourself making progress in that time frame.
• Make it clear that you’ve done your homework when asking the question. Once, I went up to someone to ask a question, and the person responded with, “did you search the wiki” and I said “no” and then I was really embarrassed and I never made that mistake again. Not to mention, the answer to my question was in the first wiki result.
• When people answer your questions, take note of how they figure out the answer themselves! Often, I’ll go ask someone a question that they don’t know the answer to, and just watching what tools they use to figure out the answer is very helpful. Write down commands you see that are useful, or wikis they referenced, or how they figured out where to start debugging, etc. This will go a long way.
• Ask questions in searchable, public forums. Does your company have an internal Q&A platform, a slack channel, or any place where engineers can go and document discussions that might be useful to others down the line? Figure out what that platform is, and utilize it!
• Understand the workflows of different people on your team. This takes time. Some people don’t mind being pinged, and don’t mind if you walk up to them at their desk randomly. Some people would prefer that you set aside time later, and don’t bug them at all. Just depends.

Oncall

Oncall is scary! Start early, no one is every fully “ready” for oncall, so just hit the ground running as soon as you can.

• Familiarize yourself with the systems your team uses for operational things — monitoring infrastructure, code rollout, testing, logging etc.
• Shadow early. A lot of knowing what to do when you’re oncall is just intuition. When you see a critical alert called “5xx error spike”, where do you even begin look to for what’s wrong? Shadow an experienced oncall and learn what datasets they look at, what related teams they loop in, what logs are useful, etc.
• Learn how to prioritize. It’s not uncommon to feel bombarded in your first few rotations, and it can feel like every issue is critically urgent. That’s probably not the case, so work with your team in your first few rotations to understand which issues are actually pressing so you can prioritize.
• Take this time to identify painful developing points or unreadable code, and craft some tech debt projects from this!
• When people ask you a question/post/assign you a task, let them know you’re looking into it, even if you don’t have an answer yet.
• As you look for an answer/work on debugging, be diligent in how you document what you’re doing. This is good practice even in not-oncall related tasks. It forces you to be able to articulate what the problem is, and how you’re fixing it. Further, this will help future oncalls, since the process will be documented somewhere. Lastly, people won’t feel the need to ping you to ask for updates because you’ll be proactive about giving those updates yourself.

Growth

• Your growth will be very natural. As you work on your new team, you’ll start to see opportunities for new projects just by virtue of being familiar with the systems. When you make a change for the 500th time to a system that has a painful testing process, you might pause and craft a project aimed at making that process better! Don’t feel rushed to get to this stage.
• Feedback! Ask for feedback and give feedback often.
• Make the other mistake: https://medium.com/@mrabkin/make-the-other-mistake-7f449077839b.
• Create a template to track how you’re doing and collect feedback over time. Make it a point to go over this with your manager every couple of weeks. No one likes a surprise when it comes to their review :)