Congratulations. Everyone have good suggestions in threads. Few other things: * Learn to measure cross-cutting, high level technical metrics. Build up your own

Congratulations. Everyone have good suggestions in threads. Few other things: * Learn to measure cross-cutting, high level technical metrics. Build up your own "fitness functions" and constantly ensure they are looking healthy. e.g. Incident metrics (https://www.atlassian.com/incident-management/kpis/common-metrics https://www.atlassian.com/incident-management/kpis/common-me...), SLOs (https://landing.google.com/sre/resources/practicesandprocesses/art-of-slos/ https://landing.google.com/sre/resources/practicesandprocess...), Lighthouse scores, Time from raising a PR to deploying in production, etc. https://www.thoughtworks.com/insights/articles/fitness-function-driven-development https://www.thoughtworks.com/insights/articles/fitness-funct... Don't be "abstract" when talking about maintainability, testability, observability, etc, but be able to support them with numbers. * Draw yourself a line. Find out where you are the decision maker and where you are not. Example: don't make your entire judgement based on "how many people can be allocated", "what's the cost", "will users like this feature", etc. Budget, people & UX are not your decision making responsibility, there are Managers, Directors, Product owners for that. Give your recommendations, but let them do their job. It's easy to fall into the "I know everything better" trap. * Don't be a "hired gun" working feature after feature, or a firefighter resolving issue after issue. Have an agenda for the technology itself that you work on 30% of the time. 6 months down the line, regardless of projects or firefighting missions – you should be in a position to prove that the technology is maturing, like: "In the last 6 months, our number of incidents/bugs has decreased from <X> to <Y>", "our time to ship features has decreased from <X> to <Y>", etc. * Don't – just don't – ever give abstract advice. A major difference between experienced and novice engineers is – giving concrete examples, facts or metrics to back up. If you don't have an example or use case, and if you just have a hunch, just keep it to yourself and move on. Remember that what you do is what other engineers will indirectly follow. You have to set engineering culture by example. If you talk abstract stuff or behave opinionated, engineers will reflect it right back.