This is Part 1 of a two-part series.
Going from a junior- to a mid-level software engineer has always been fairly straightforward: gain experience and competency by fulfilling your day-to-day tasks. You should be able to handle any engineering work you’re assigned. Your manager should be using words like “reliable” and “efficient” to describe you, meaning you deliver mostly bug-free work in a timely manner.
Once you reach mid-level, however, it becomes harder and harder to continue leveling up. Here are a few things you can do to help yourself stand out. Keep in mind it’s important to keep doing what you’re already doing, so these should be in addition to, not in place of, your existing responsibilities.
Find small things to fix/improve
Every software company has tech debt and bottlenecks that everyone knows and complains about, yet they persist simply due to inertia. Seek those things out, fix them, and your coworkers will thank you. Examples include fixing console warnings, stabilizing flaky tests, or improving the run time of your test suite. The kind of work that won’t get assigned in a ticket and so it slips between the cracks, but that can make real quality of life improvements for the engineering team.
You can gain plenty of knowledge and experience by doing the typical engineering work of features and bug fixes, but once you begin exploring the edges of your codebase and the systems that support it, you’ll naturally begin to operate at a more senior level.
Update your dependencies
At my current job, I started an initiative to track which dependencies were out of date and work toward reducing that number. Again, this is the kind of tech debt that’s easy to let slide, but it can have implications beyond the engineering team. Updated dependencies means you’re getting security fixes (your Dev Ops team will thank you) as well as new features you can take advantage of (looking at you, Product).
Once again, this also helps you personally as an engineer. When you encounter breaking changes while upgrading, it’ll force you to read through the docs and understand the changes. Maybe something you used to struggle with will suddenly click. Maybe you’ll realize you don’t even need that dependency (in my case, I found over two dozen dependencies that were no longer even being used). Or maybe you could become the person who’s trusted with deciding whether to use Package A or Package B.
Take ownership of something
Become the owner and/or domain expert of some facet of your codebase. Maybe your team lacks shared formatting and linting standards. Maybe you use GraphQL (or any other technology) but no one knows the best practices. Or maybe there’s some pattern or abstraction you can introduce to improve consistency and maintainability.
Once people see you as the go-to person for something, you start to become indispensable.
Share the knowledge
When you do any of the above things, it’s important to share what you’ve learned, whether through Slack updates, documentation, or both. Never in a braggy or show-off way, but for purposes of knowledge sharing—although, yes, doing this can go a long way toward demonstrating seniority. As an added bonus, explaining things always forces you to have a deeper understanding of those things.
And that gets at what being senior is all about. Over time, it becomes less about your ability to produce great code. That should be a given. Senior engineers are leaders, and that means leading by example and thinking beyond the normal day to day, focusing on the long-term health of their team.
Top comments (0)