5 Things I Learned my First Year as a Sr Developer

Stop taking every story that comes your way

Focus on tasks that increase developer velocity. (Best practices, coding guidelines, knowlege transfers, mentoring).

There will be a phase where a lot of your time is spent on many random calls to help junior devs when they get stuck. This may stress you because you don't have the time to complete stories you know you can do.

Trust the process and try to find patterns in what they are getting stuck on. This will give you hints on where you can improve the codebase to make it easier to iterate upon. As you help unblock the other developers you will start to see the pain points in the codebase while also building rapport with your team members.

Dont leave anyone behind

Take your time with this it will take practice. Your most useful task will to be identify and define new patterns for the codebase by refactoring new interfaces and automation into the codebase.

As you find refactor opportunities, and you create stories for yourself to track them, think about how you will teach the others about the new patterns you build.

When you introduce a refactor some developers may interpret this as you pulling the rug from under them. Understand that they likely aren't upset that you're trying to make things better for everyone, they're upset that your change requires them to re-read and re-learn large portions of the codebase.

The larger the refactor, the more time you should be putting into documentation, pair programming, and presentations. This is so that you can, not only make the other devs comfortable with your changes, but also help align them with the reasoning for why this will be an improvement.

Learn the entire lifecycle of your codebase

Understand how to build, test, and deploy the application you're contributing to. (Not every team has a dedicated devops engineer, usually they are distributed across several teams). This will be helpful when deployments or continuous delivery goes wrong. If you can do this, you likely will be at a point of mastery in your 'silo'.
This will help you to quickly solve problems and free up some of your time to learn on the side, or take on my meetings / decisions for your team.

Your time is now much more costly

This one is a double edge sword. You may want to take an interesting feature from the backlog, spend extra time making the ui pixel perfect, or more perfectly abstract an interface on the backend. However this may not always be the immediate need, and the cost of misdirecting your efforts could set back the team much longer.

The opposite is true as well. You have put more tools into your toolbox over the years and that enables you to see things that others may not. You can clearly identify a problem and define a path forward. You can see abstractions that others may not.

Instead, set them up for success. Get the task started to a point where another developer can clone your branch and just get to working on the problem.
Set up all the inputs for them, or possibly, even a unit test for them to fulfill. This way you can meet with them, explain the problem and what you are looking to have accomplished, let them ask any initial questions before getting started, and be on your way.

Having a clearly defined path ahead will make them much more comfortable with taking on challenges.
This way, you get your beautiful interface, your team gets the expertise they need from you, and the junior gets an opportunity to grow and succeed.

This is how you amplify growth.

Your code is useless if you cannot get it into production

Not every team will have a dedicated ops personnel, or a dedicated test engineer, etc. Additionally, an adaptive cross-functional team is the most agile.

Therefore, it is important to understand all of the interactions that happen in order to bring your team's code into action. You are expected to adjust yourself to fill in the needs of the team, and from time to time you will make large pivots from coding, to fixing deployments, training a developer in unit testing, or triaging issues on the running application.

Rather than focusing all of your efforts into the codebase, offload those tasks that have well defined patterns to the other developers by setting them up for success. This will free you up to put some time into understanding your ci process, building elegant e2e tests, understanding your Helm charts, and learning Kubernetes the hard way.

As you pave the path forward in many directions, if you can establish patterns and reasonable abstractions, you can amplify your efforts by charting out the path to success and bringing the others along with you.