5 Lessons From My First Year as a Software Engineer

Saad Masood
6 min readMar 4, 2021

Getting your first software engineering job is a sweet, sweet feeling.

You’ve probably had to go through tons of interviews to get the job. Not to mention, work behind the scenes to make sure the interviews are a success and you land them in the first place — the hours spent on LeetCode, working on open-source code or crafting pet projects, working through a computer science education in college or committing yourself to build software skills on your own time.

But landing that first job is simply the start. The road ahead bound to bring plenty of challenges and milestones.

I’ve learned plenty in my first year as a software engineer. There are a few key lessons that stand out though — traits and habits that have propelled my growth as a software engineer.

1. Communicate thoroughly 📣

I know, it’s super cliché. Inside or outside of software engineering, every job posting you come across demands strong communication skills.

But there are specific ways to apply strong communication in your role as a software engineer. You’re — presumably — not working alone, rather in a team. Your team depends on you, and you on them.

Communicating through code 💻

Your code is a form of communication with your team. Someone will be reviewing it before your changes make it into the codebase. Others will be responsible — alongside yourself — for maintaining that code over time. So make sure your code is readable!

  • Use descriptive variable names.
  • Write small, specific functions.
  • Follow formatting and styling guidelines your team has. If your team doesn’t have specific guidelines, maybe you can be the one to introduce them! (go off popular ones like Google’s Style Guide)
  • Write comments to explain potentially ambiguous code. When you’re writing code, you’re aware of the edge cases and feature decisions that are driving it. Down the line, someone reading your code (maybe even your future self) may not have the context that existed when it was written.

Document everything! 📝

Hashing out ambiguities, or clarifying scope with a product manager or engineering lead on a complex feature? Make sure you note down everything you discuss, sum it up in an email, Slack/Teams message, and send it over to your product manager or lead and any other stakeholders concerning the feature.

Better yet, if your team uses project tracking software (e.g. Jira, VersionOne, Azure DevOps) make a note of it there.

This makes sure everyone is on the same page. Plus, if someone else works on the feature in the future, they’ll have a clear reference to why certain decisions were made, any edge cases, or other pertinent information.

While working on a feature, we’re revved up. The feature is the center of our world. We feel like we’ll always retain the key details on why certain decisions were made or how strange edge cases pop up.

Well, we’re wrong. 😅

Humans are pretty forgetful. A few months later, a bug may come up. You may vaguely recall reasons that could be causing it, but having logs — whether they are small snippets in a Word doc, starred emails, preserved Slack/Teams messages, or full-fledged documentation — will help you quickly narrow down root causes and expected behavior.

2. Go out of your comfort zone 👀

It’s daunting to enter your first software engineering role. There are a lot of unknowns. It’ll take some time to get a keener sense of the product you’re building and feel comfortable in your team’s codebase. That’s expected, so your team will likely start you off with small bug fixes, refactoring tasks, and minor features to get you ramped up.

That shouldn’t stop you from taking on features that may be out of your comfort zone though. Show interest in projects that you care about and want to work on. Make sure your manager and team lead know what you want to work on. The only way you will learn and grow is by getting out of your comfort zone and working on tough engineering problems.

So if you’re asked to work on something that feels foreign, say yes. Don’t let imposter syndrome get the best of you!

Side note: I highly recommend subscribing to Dan Moore’s Letters To A New Developer. It’s a very comforting way to ground yourself and know you’re not alone in your struggles as a fresh software engineer, as much as it can feel like you are sometimes!

It’s ok to feel overwhelmed when you’re starting out and there’s tons to learn. You’ll figure it out. Remember, your team is there to help you. Don’t be afraid to lean on them. They want you to succeed and prosper more than you know! Which brings me to my next point..

3. Ask for help when you need it 👋

You have to strike a balance between powering through challenging projects and knowing when to ask for help.

There comes a point where you’ve tried everything you can to fix a bug, handle an edge case, or come up with the ideal design to implement a feature. Eventually, you hit a brick wall. That’s when you ask for help — only when you’ve exhausted all avenues you can think of trying on your own!

Ask for help to fix root causes rather than putting band-aids over bad code!

When you do ask for help, be specific and provide context. Let whoever you’re asking know exactly what the problem is, and the different ways you’ve tried to do to solve it. Your manager, team lead, and the senior engineers on your team will be more than willing to help you. You’re someone new not only to the team but to the software engineering industry! And they know that. They know you’ll have questions, and they’ll be happy to help (they were once just starting out too!)

Don’t be afraid to ask a question because it may be stupid. It’s better to clear out ambiguities and assumptions than let them fester.

Don’t let your ego get in the way. You’re new and want to prove yourself, of course. But asking for help isn’t a sign of weakness. Rather than overworking yourself to meet a deadline, or pulling your hair out trying to fix a strange bug, ask for help when you need it.

4. Learn something new every day 📖

The software engineering industry moves fast. The hot, new framework right now may be done and dusted in a few years. You have to keep up with what’s going in the industry. You have to keep your skills sharp. ⚡️

So take 30 minutes out of your day to learn something new. Follow influential folks on Twitter and see what they’re posting about. Subscribe to newsletters in your niche (e.g. JavaScript Weekly, Programming Digest, Pointer).

Don’t burn yourself out trying to keep up with new technologies though. Skim the surface and only deep dive into things you find compelling.

Framework fatigue is real 😓

5. Go beyond your role’s responsibilities 🚀

To progress in your career, you have to go beyond what your current job responsibilities entail. How can you do that as a software engineer?

  • Are you working a on piece of code that looks like it could use refactoring? Time and scope permitting, refactor it alongside your main task.
  • Is the component you’re working on missing some unit tests that should have been there? Write them.
  • Is the build broken? Try to fix it.
  • Is someone asking for help on your team’s group chat? Try and help them out.
  • Is there a tool or engineering process you think your team is missing that would be helpful? (e.g. CI/CD, linting, integration testing, style guidelines, new libraries, etc) Put together a Proof of Concept, present it to your team, and see if you can bring it in.

Lessons aside… 😂

Remember to have fun! As a software engineer, your code is bringing a product to life. You’re helping users of your product solve a problem, making their life a little easier! Relish that. Be proud of yourself for getting your foot in the door, and look forward to the journey ahead 🎉

--

--

Saad Masood

NYC-based software engineer striving for a better internet. Adventitious writer. Electronic music enthusiast.